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SECTION  I 


INTRODUCTION 

Tne  Air  Force  Data  Services  Center  (AFDSC)  at  the  Pentagon  has 
recently  acquired  the  Honeywell  Multiplexed  Information  and  Computing 
Service  (Multics)  to  be  used  in  a general  timesharing  environment.  In 
the  past,  the  system  could  only  operate  at  a single  level  of  classifi- 
cation because  Multics  did  not  support  any  notion  of  Department  of  De- 
fense classifications  or  clearances.  Numerous  enhancements  to  Multics 
have  been  provided  by  Honeywell  to  allow  a multi-level  operation  in 
which  "non-malicious"  users  of  various  clearances  can  use  the  system 
at  the  same  time. 

These  security  enhancements  have  been  incorporated  into  Multics 
as  part  of  the  standard  product  for  use  by  any  installation  having  a 
need  for  such  controls.  Although  the  security  features  allow  open  op- 
eration at  all  classification  levels,  the  AFDSC  will  provide  a "benign 
environment"  by  administratively  limiting  access  to  the  system  to  se- 
cret and  top  secret  cleared  individuals.  Reasonable  assurance  that 
the  controls  function  properly  will  be  provided  by  these  test  proce- 
dures. This  report  describes  the  final  version  of  the  test  proce- 
dures . 


BACKGROUND 

work  is  currently  in  progress  to  develop  a validated  kernel-based 
Multics  that  can  support  multi-level  operation  in  an  open  environment 
[1].  A security  kernel  has  been  implemented  in  a small  operating  sys- 
tem for  a minicomputer  [2],  and  a validation  methodology  has  been  for- 
mulated [3].  However,  until  a validated  Multics  system  becomes  avail- 
able, there  is  the  need  for  an  interim  implementation  at  AFDSC  that 
provides  the  necessary  controls  with  reasonable  assurance  that  the 
controls  function  properly. 

A study  was  undertaken  to  determine  "how  secure"  Multics  was  cur- 
rently, as  a guide  to  the  degree  of  security  that  may  be  provided  by 
an  enhanced  version  that  incorporates  additional  security  controls 
[4],  It  was  determined  that  Multics  as  it  exists  could  not  be  run  in 
an  open  multi-level  environment,  but  that  with  certain  enhancements 
and  external  procedural  controls,  it  could  be  run  in  a limited  con- 
trolled (benign)  environment.  At  the  AFDSC  the  benign  environment  is 
provided  by  limiting  access  to  the  system  to  individuals  with  at  least 
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a secret  clearance. 


In  order  to  determine  in  detail  what  kind  of  enhancements  should 
be  made  to  Multics,  representatives  from  the  Air  Force  (AFDSC  and 
Electronic  .Systems  Division),  Honeywell  and  MITRE  participated  in  a 
series  of  Design  Analysis  meetings  between  August  and  October,  1973. 
Tne  goal  of  the  Design  Analysis  was  to  define  a Multics  implementation 
that,  through  addition  of  security  controls  to  the  existing  system, 
could  provide  a reasonable  degree  of  security  in  an  unvalidated  sys- 
tem, while  maintaining  as  close  as  possible  the  existing  user  inter- 
faces. In  fact,  to  installations  that  do  not  choose  to  use  the  secu- 
rity controls  (e.g.,  a single  level  installation),  the  enhancements 
should  be  completely  invisible.  Also,  as  far  as  was  feasible,  many  of 
the  concepts  involved  in  the  design  of  a validated  system  were  to  be 
incorporated  into  the  enhancements,  thereby  facilitating  a smooth 
transition  (for  tne  user)  when  the  validated  kernel-based  system  is 
implemented . 

One  of  the  important  concepts  incorporated  as  part  of  the  latter 
goal  is  that  of  the  "security  perimeter"  inside  which  all  program  mod- 
ules are  considered  "security  sensitive".  Although  there  is  no  secu- 
rity kernel,  these  security  sensitive  modules  have  been  identified  and 
design  and  modification  of  these  components  are  subject  to  close  scru- 
tiny . 

The  result  of  the  Design  Analysis  meetings  was  a document  [5]  de- 
scribing the  enhancements  that  ideally  should  be  incorporated . Due  to 
budget  and  schedule  constraints,  however,  the  actual  implementation 
differs  in  several  minor  ways  from  that  described  in  the  document. 


DESCRIPTION  OF  SECURITY  ACCESS  CONTROLS 
Basic  Multics  Access  Controls 

The  basic  Multics  access  controls  allow  individual  users  to  con- 
trol access  to  information  in  a discretionary  manner  through  a system 
of  access  control  lists  (ACLs).  A user  who  creates  a Multics  file, 
called  a segment,  can  make  that  segment  accessible  or  inaccessible  to 
other  users  by  specifying  in  the  access  control  list  for  that  segment 
the  users  (or  groups  of  users)  to  which  he  wants  to  grant  or  restrict 
access,  and  by  specifying  the  type  of  access  to  be  granted  to  each 
user.  The  types  of  access  defined  within  Multics  are:  read,  write, 
and  execute.  Every  time  a user  accesses  a segment,  his  access  rights 
are  checked  in  the  ACL  for  that  segment  and  appropriate  privileges  are 
given. 
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Multics  Security  Controls 


With  the  incorporation  of  security  controls,  further  "non-discre- 
tionary"  access  rules  are  enforced  tnat  are  not  normally  controllable 
oy  the  user.  In  the  military  "paper"  system  each  person  has  a specif- 
ic security  clearance  and  each  document  has  a classification.  A per- 
son can  only  read  a document  if  his  clearance  is  greater  than  or  equal 
to  the  classification  of  the  document  and  if  the  owner  of  that  docu- 
ment has  granted  him  "need  to  know"  by  letting  him  see  it.1 

The  ACL  controls  in  Multics  only  implement  the  need  to  know  capa- 
bility for  segments.  In  order  to  duplicate  the  military  scheme  an  ad- 
ditional attribute  has  been  associated  with  each  process  and  each  seg- 
ment. This  attribute  of  a process  is  called  the  "authorization"  and 
the  attribute  of  a segment  is  called  "access  class".  The  terms  "au- 
thorization" and  "access  class"  are  Multics  terms  synonymous  with  the 
military  terms  "clearance"  and  "classification".  The  Multics  terms 
will  oe  used  throughout  this  report. 

Tne  clearance  of  each  user  is  stored  in  the  system  and  interpre- 
ted as  a maximum  autnorization  that  the  user  is  allowed  to  use.  When 
the  user  logs  in  and  verifies  his  identity  through  the  use  of  a pass- 
word, tnis  maximum  authorization  plus  other  factors  are  used  to  deter- 
mine tne  authorization  of  the  process  to  be  created  on  the  user's  be- 
half. After  process  creation,  only  the  process  authorization  is  used 
in  determining  access  rights.  Processes  with  the  same  authorization 
have  exactly  the  same  access  privileges  (though  still  subject  to  ACL 
controls)  even  though  the  respective  users  may  have  different  maximum 
authorizations.  For  example,  a user  identified  by  the  system  as  a se- 
cret cleared  individual  may  login  at  the  unclassified  level  and  his 
access  privileges  are  the  same  as  if  he  himself  had  no  clearance. 

Thus,  on  each  access  a process  makes  to  a segment,  the  authoriza- 
tion of  the  process  and  the  access  class  of  the  segment  are  compared 
against  each  other.  If  both  are  equal,  or  if  the  authorization  is 
greater  than  the  access  class,  the  process  may  read  or  execute  the 
segment  provided  the  ACL  of  the  segment  allows  that  process'  user  to 
read  or  execute.  The  ability  to  write  into  a segment  is  granted  only 
if  tne  process'  authorization  is  equal  to  the  segment's  access  class, 


Classification  and  clearance  as  used  in  this  document  have  two 
components:  a level  and  a category  set.  The  exact  definition  of 

classification  and  clearance,  and  the  possible  relationships  between 
tnem,  will  be  discussed  later  (See  page  12).  In  the  context  of  the 
kernel  and  validation  work,  the  term  "security  level"  is  used  to  refer 
to  this  two-component  structure,  where  "classification"  is  the  first 
component  and  category  or  compartment  is  the  second  component. 
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and  if  "write"  is  specified  for  that  user  on  the  ACL  of  the  segment. 

The  restriction  on  write  access  is  not  a direct  military  require- 
ment, but  is  a special  case  of  tne  “-property,  a security-preserving 
relation  that  simplifies  implementation  of  security  controls  [6].  The 
•-property  is  actually  somewhat  broader  in  that  it  allows  a process  to 
write  to  segments  of  a higher  access  class,  but  "write  up"  has  been 
eliminated  in  the  Multics  implementation  because  it  is  a complication 
and  of  no  use  to  users. 


extended  Security  Controls 

Multics  contains  more  tnan  just  segments  and  user  processes.  The 
above  description  of  the  security  controls  only  satisfies  the  general 
military  requirements.  Tnese  controls  are  ineffective  by  themselves; 
security  controls  must  be  applied  to  all  areas  of  Multics. 

The  Multics  file  system,  which  contains  all  the  segments  within 
the  system,  is  a hierarchy  as  shown  in  Figure  1.  The  circles  in  the 
figure  indicate  segments  and  the  rectangles  are  directories.  Directo- 
ries are  special  kinds  of  segments  that  are  not  directly  accessible  to 
the  user,  but  can  only  be  read  or  written  in  an  interpretive  mode 
through  system  procedures.  Directories  are  used  to  hold  the  names, 
locations  and  otner  attributes  of  segments  and  subdirectories  con- 
tained within  tnem. 


i-iultics  defines  three  types  of  access  to  directories:  status, 

modify,  and  append,  and  these  are  treated  in  a manner  similar  to  the 
access  modes  of  segments.  A simple  extension  of  segment  security  con- 
trols would  allow  us  to  define  the  types  of  controls  to  be  placed  on 
directories:  "status"  can  be  considered  the  same  as  "read",  and  "modi- 
fy” and  "append"  can  be  treated  the  same  as  "write".  The  application 
of  security  controls  to  directories  thus  appears  to  be  straightfor- 
ward. Tnere  are,  however,  several  problems  involving  the  various 
types  of  control  information  stored  in  each  directory. 


In  order  to  handle  many  of  these  problems,  tne  security  controls 
for  Multics  require  tnat  segments  within  a directory  have  an  access 
class  equal  to  that  of  the  directory.2  Directories  within  a direc- 
tory must  have  an  access  class  equal  to  or  greater  than  that  of  the 
parent  directory.  A directory  whose  access  class  is  greater  than  that 
of  its  parent  is  called  an  upgraded  directory.  With  these  restric- 
tions the  access  classes  increase  as  one  goes  down  in  the  hierarchy. 
Information  about  a segment,  such  as  length,  date  used,  etc.,  which  is 


p 

Tnere  is  the  special  case  of  upgraded  message  segments  discussed  on 
page  58. 
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Figure  1.  Multics  Directory  Hierarchy 


contained  in  the  parent  directory,  has  the  same  access  class  as  the 
segment.  Similar  information  about  a directory,  however,  must  be 
treated  in  a special  way.  The  special  access  to  directories  will  be 
discussed  in  Section  III. 

The  above  contraints  on  access  classes  of  segments  and  directo- 
ries are  necessary  for  the  proper  enforcement  of  the  security  con- 
trols. In  order  to  insure  that  the  hierarchy  is  always  consistent 
with  respect  to  these  rules,  there  is  a "security  out  of  service"  bit 
for  each  segment  or  directory  that  can  be  set  by  the  system  if  an  in- 
consistency is  detected.  A user  is  not  allowed  to  access  a directory 
or  segment  whose  security  out  of  service  bit  is  set.  This  bit  is  not 
used  merely  to  detect  bugs  in  system  software  --  special  processes  or 
privileged  users  could  inadvertently  cause  an  inconsistency  to  occur. 
The  security  out  of  service  bit  limits  the  damage  that  a user  can  do 
in  an  inconsistent  portion  of  the  hierarchy. 

Additional  Controls 


The  Multics  hardware  supports  a set  of  eight  ordered  protection 
domains,  known  as  rings,  within  a process.  A process  has  the  greatest 
privilege  while  running  in  ring  zero,  and  the  least  privilege  while  in 


11 


ring  7.  Rings  0-3  are  reserved  for  system  software  and  rings  4-7  are 
available  for  users.  Most  user  level  code,  by  default,  runs  in  ring 
4,  which  is  also  known  as  the  user  ring.  In  addition  most  of  the 
non-critical  software  in  Multics  runs  in  ring  4.  Ring  zero,  also  re- 
ferred to  as  hardcore,  and  ring  1,  contain  the  software  critical  to 
keeping  tne  system  running  and  protecting  access  to  information.  The 
security  controls  and  all  other  access  controls  are  the  responsibility 
of  ring  zero  and  ring  1 software.  User  written  programs  can  invoke 
inner  ring  primitives  by  calling  specific  entry  points  in  hardcore  or 
ring  1 directly.  Commands  typed  in  by  the  user  at  his  terminal,  now- 
ever,  are  handled  by  system  software  running  in  the  user  ring,  wnicn 
tnen  may  invoke  inner  ring  primitives  to  accomplish  its  task. 

For  the  most  part  the  ring  structure  will  be  ignored  during  the 
test  procedures.  However,  it  is  necessary  to  be  always  aware  of  the 
ring  in  which  software  under  test  normally  runs.  User  written  soft- 
ware can  arbitrarily  replace  any  software  in  ring  4.  Inner  ring  soft- 
ware can  only  be  replaced  by  the  installation.  Thus,  the  validity  of 
any  test  of  user  ring  software,  or  of  any  test  that  utilizes  user  ring 
software  not  part  of  the  test  package,  must  be  considered  in  view  of 
the  possibility  that  such  software  may  be  purposely  or  inadvertently 
bypassed  by  the  user. 


DEFINITIONS 

The  terms  "access  class"  and  "authorization"  are  general  terms 
for  Multics  that  describe  how  a process'  access  to  an  object  (e.g.  a 
segment,  directory,  etc.)  is  determined.  Access  class  is  an  attri- 
bute of  an  object  and  authorization  is  an  attribute  of  a process.  Au- 
thorization and  access  class  are  actually  identically  structured  — 
the  different  terms  are  meant  only  to  indicate  to  what  they  apply 
(process  or  object). 

Classification  and  clearance  are  very  specifically  defined  in  the 
military.  In  the  computer,  the  structure  of  an  access  class  or  au- 
thorization is  represented  as  follows: 

(1)  a level  number,  which  is  an  integer,  and 

(2)  a category  set,  which  is  represented  in  a computer  as  a string 
of  bits,  any  combination  (or  none)  of  which  may  be  on. 

The  Multics  security  controls  are  designed  to  operate  using  any  kind 
of  access  class  structure  that  may  be  defined  for  the  installation. 
However,  we  will  in  this  report  assume  tnat  an  access  class  consists 
of  a level  and  a category  component.  The  test  procedures  are  designed 
for  the  most  part  to  nandle  the  above  definition  of  access  class,  and 
the  ArDSC  uses  this  definition. 


Because  an  access  class  is  more  complex  than  just  a level  number, 
the  relationsnips  between  two  access  classes  must  be  strictly  defined. 
(The  set  of  access  classes  is  partially  ordered.)  The  possible  rela- 
tionships between  two  access  classes,  A and  B,  are  defined  below.  The 
notation  level (A)  and  cat(A)  refer  to  the  level  number  of  A and  the 
category  set  of  A respectively. 

1.  A is  "less  than"  B if: 

level(A)  < level(B)  and  cat(A)  is  a subset  of  cat(B); 

or  level(A)  = level(B)  and  cat(A)  is  a proper  subset  of  cat(B). 

2.  A is  "equal  to"  B if: 

level(A)  = level(B)  and  cat(A)  = cat(B). 

3.  A is  "greater  than"  B if: 

level(A)  > level(B)  and  cat(B)  is  a subset  of  cat(A); 

or  level(A)  = level(B)  and  cat(B)  is  a proper  subset  of  cat(A). 

4.  A is  "isolated  from"  B if: 

none  of  the  above. 

These  definitions  are  consistent  in  the  normal  way  in  that  A "less 
than"  B implies  B "greater  than"  A.  Note,  however,  that  not  "less 
than"  does  not  necessarily  imply  "equal  to"  or  "greater  than",  since 
the  category  sets  may  be  isolated.  The  specific  requirement  cited 
near  the  bottom  of  page  9 for  read  and  write  privilege  assumes  the 
above  definitions  of  these  relationships.  When  one  of  these  four  re- 
lationships is  referred  to  within  this  report,  it  will  be  written  be- 
tween quotes  to  avoid  confusion  with  the  numeric  comparisons  between 
level  numbers. 

In  some  places  the  term  "minimum"  is  used  in  reference  to  a group 
of  access  classes  or  authorizations.  This  term  is  defined  in  the  usu- 
al sense:  the  minimum  of  a group  of  access  classes  is  the  "greatest” 

access  class  that  is  "less  than"  or  "equal  to"  each  of  the  access 
classes  in  the  group.  This  minimum  can  be  calculated  as  the  numerical 
minimum  of  the  levels  and  the  intersection  of  all  the  category  sets. 
Note  that  the  minimum  of  a group  of  access  classes  is  not  necessarily 
"equal  to"  any  of  the  members  of  the  group. 


Notation 


Throughout  this  report  references  will  be  made  to  specific  names 
of  levels  and  categories  that  make  up  an  access  class.  The  names  for 
levels  are  similar  to  those  adopted  by  the  military  classification 
system  and  were  chosen  because  they  are  more  meaningful  than  names 
like  "level-1",  "level-2",  etc.  Of  course,  any  names  in  use  at  a par- 
ticular installation  whose  security  controls  are  to  be  tested  may  be 
substituted.  However,  if  substitutions  are  made  the  same  relation- 
ships between  the  levels  must  be  maintained  throughout  in  order  for 
tne  discussion  in  this  report  to  be  consistent. 

Each  level  name  has  a long  and  short  form  that  may  be  used  inter- 
changeably. The  long  and  short  forms  of  the  level  names  used  within 
this  report  are  (in  increasing  order): 

unclassified  U 
confidential  C 
restricted  ft 
secret  S 

top  secret  T 

These  levels  need  not  be  exactly  one  unit  apart  as  long  as  the  order- 
ing is  maintained  (e.g.,  there  may  be  additional  levels  between  C and 
R).  The  only  assumption  made  in  this  report  is  that  the  lowest  level 
(unclassified  or  U)  is  actually  equivalent  to  the  lowest  level  availa- 
ble on  the  system  at  the  installation.  This  lowest  level  is  also  re- 
ferred to  as  "system_low" . In  addition,  "system_high"  is  used  to  re- 
fer to  the  highest  authorization  level  with  all  categories  available 
on  the  system.  It  is  not  important  whether  the  level  number  of 
system_high  is  equal  to  or  greater  than  top  secret. 

The  names  of  the  categories  are  arbitrarily  defined  below: 

cl  1 
c2  2 
c3  3 
c4  4 
c5  5 
c6  6 
c7  7 

The  long  forms  are  the  names  beginning  with  "c",  and  the  short  forms 
are  just  the  numbers.  There  is,  of  course,  no  ordering  of  categories, 
so  any  substitutions  may  be  made. 
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A complete  access  class  or  authorization  is  written  as  a level 
name  followed  by  the  category  names  separated  by  commas,  e.g.: 

secret ,c 1 ,c2,c3 
or  S, 1 ,2,3. 
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SECTION  II 


PHILOSOPHY  OF  OPERATION 


SYSTEM  ENVIRONMENT 
Purpose  and  Scope 

Trie  main  purpose  of  the  test  procedures  is  to  check  the  security 
control  enhancements  at  initial  installation  at  the  AFDSC  site  and  at 
all  new  system  releases.  The  procedures  are  designed  to  verify  that 
the  security  controls  perform  exactly  as  specified.  Thus  it  is  neces- 
sary to  check  both  that  illegal  operations  are  inhibited  and  that  le- 
gal operations  are  allowed.  This  latter  verification  is  necessary  be- 
cause a bug  tnat  inhibits  a legal  operation  might  very  well  indicate  a 
malfunction  that  could  lead  to  compromise. 

This  report  describes  only  the  tests  of  the  security  controls  as 
enhancements  to  Multics.  Except  for  one  case,  the  basic  Multics 
controls  (access  control  lists,  rings,  user  authentication,  etc.)  that 
have  supposedly  not  been  modified  from  the  original  Multics  design  are 
assumed  to  work  properly.  Failure  of  these  latter  controls  could  be 
an  indication  of  some  bug  that  might  lead  to  a compromise  situation, 
and  must  therefore  be  included  in  a complete  test  system.  However, 
testing  of  all  of  the  Multics  controls  is  beyond  the  scope  of  this 
project . 

Although  the  AFDSC  will  use  the  enhanced  Multics  only  with  secret 
and  top  secret  cleared  users,  the  tests  are  designed  to  check  all  the 
controls  in  a general  manner.  Thus  various  levels  and  categories  will 
be  assigned  to  users  and  projects.  The  only  installation-specific 
tests  are  the  I/O  tests,  where  a given  system  configuration  of  periph- 
eral devices  must  be  available. 

Isolation  of  Tests 


Since  all  the  security  controls  are  implemented  in  software,  it 
is  unnecessary  to  continuously  monitor  the  system  as  with  a hardware 
test  program  — there  is  little  meaning  in  running  the  tests  more  than 
once  after  a system  release  because  software  does  not  deteriorate. 
There  is  also  no  point  in  trying  to  detect  unauthorized  modification 
to  system  software  by  testing,  since  the  assumption  is  that  there  are 


^i.e.,  the  segment  ACL  controls  discussed  on  page  43. 


no  malicious  users,  and  a penetrator  who  can  modify  system  software 
can  easily  prevent  his  modifications  from  being  detected.  Of  course, 
there  is  nothing  preventing  an  installation  from  running  these  tests 
more  frequently  if  it  chooses. ^ 

Although  the  entire  test  system  will  usually  be  run  as  a whole 
unit,  it  helps  if  the  various  tests  can  be  logically  grouped  into  sec- 
tions that  are  isolated  from  one  another  so  that  any  one  group  of 
tests  can  be  run  without  running  the  others.  There  are  several  rea- 
sons why  this  grouping  is  useful. 

1.  Suspected  subversion  attempts,  bugs  or  random  hardware  fail- 
ures such  as  disk  errors  could  modify  system  directories  and  librar- 
ies. If  a problem  in  a particular  area  is  suspected,  just  those  tests 
for  that  area  can  be  run. 

2.  Some  of  the  tests  must  be  done  manually  and  are  time  consum- 
ing. In  case  of  an  operator  error  while  running  one  group  of  tests, 
it  should  not  be  necessary  to  restart  the  entire  test  sequence,  but 
only  to  restart  that  group  of  tests. 

3.  Logical  grouping  helps  to  localize  system  bugs.  Often  a bug 
in  one  area  will  affect  other  areas.  If  the  results  of  one  group  of 
tests  depend  on  the  results  of  a previous  test,  and  the  previous  test 
fails  due  to  a system  bug,  then  further  testing  is  not  possible,  and 
other  bugs  might  be  undetectable  until  the  previous  bug  is  fixed. 

4.  Debugging  of  a new  system  is  greatly  simplified  if  tests  can 
be  run  tnat  only  apply  to  the  area  being  debugged.  (It  is  not  clear 
whether  these  test  procedures  will  actually  be  used  in  debugging,  how- 
ever. ) 


5.  Logical  grouping,  of  course,  simplifies  the  structure  of  the 
tests  themselves.  This  is  a very  important  point  due  to  the  fact  that 
test  programs  cannot  usually  be  completely  checked  out  by  just  "run- 
ning" them.  To  make  absolutely  sure  that  a test  program  will  detect  a 
given  system  failure,  one  often  has  to  introduce  or  simulate  a system 
bug.  Mot  all  system  bugs  can  be  effectively  simulated  without  modifi- 
cation to  the  system,  so  source  code  inspection  must  be  used  as  a 
method  of  debugging.  This  inspection  becomes  more  reliable  as  the 
test  programs  become  less  complex  and  more  structured. 


a 

It  must  be  emphasized  that  a "trap  door"  installed  in  system  soft- 
ware by  a penetrator  may  be  virtually  impossible  to  detect  by  any 
means  of  testing  or  inspection.  Only  validation  of  software  and  prop- 
er configuration  control  will  assure  that  trap  doors  cannot  be  insert- 
ed. 
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Because  each  group  of  tests  is  independent  of  the  others,  func- 
tions tested  by  one  group  snould  not  be  used  in  another  group  unless 
absolutely  necessary.  For  example,  the  tests  for  creation  of  segments 
are  in  a different  group  from  tnose  that  access  the  segments  them- 
selves. This  latter  group  should  not  create  segments  that  it  intends 
to  access.  Rather,  a set  of  already  existing  segments  should  be  pro- 
vided. In  this  way,  a bug  in  the  segment  creation  controls  will  not 
manifest  itself  as  a segment  access  bug.  The  test  environment  ini- 
tialization procedures  discussed  on  page  26  create  the  segments  and 
other  permanent  data  bases  necessary  to  run  the  tests. 

It  may  seem  more  esthetic  for  a single  test  program  to  test  ev- 
erything, creating  and  deleting  all  the  data  bases  it  might  need.  But 
such  a program  could  tend  to  be  very  obscure  and  complex.  The  extra 
cost  of  having  segments  and  directories  around  permanently  is  negligi- 
ble compared  to  the  advantages  of  simpler  test  procedures. 

It  is  of  course  not  possible  to  completely  isolate  all  groups  of 
tests  from  one  another.  The  mere  act  of  logging  in  requires  creation 
of  many  segments  and  checking  of  segment  access  classes.  An  attempt 
has  been  made,  however,  to  minimize  the  assumptions  that  one  group 
makes  about  the  performance  of  features  tested  in  other  groups. 

Unprivileged  Test  Programs 

All  test  programs  in  this  series  are  run  at  a level  of  privilege 
appropriate  to  that  of  the  area  being  tested  --  mostly  at  the  level  of 
the  average  user.  Some  tests  can  be  greatly  simplified  if  they  are 
run  at  some  "system  level"  with  extra  privileges.^  But  whenever  a 
test  procedure  gets  more  privilege  than  the  area  that  it  is  testing, 
part  of  the  controls  are  bypassed  and  proper  function  of  the  controls 
cannot  be  guaranteed. 

Most  Primitive  Functions 

When  a user  calls  a subroutine  that  eventually  invokes  some  hard- 
core or  inner  ring  primitive,  he  often  does  not  know  or  care  whether 
various  controls  and  tests  are  made  within  the  primitive  function  or 
in  higner  level  software  (i.e,,  user  ring  software).  For  example,  the 
user  level  "delete"  command  can  first  check  to  see  if  the  segment  to 
be  deleted  exists  and  whether  the  user  has  access  (by  invoking  other 
hardcore  primitives)  before  cabling  the  hardcore  delete  subroutine. 


JFor  example,  the  login  tests  described  in  Section  III  could  be  done 
automatically  if  one  process  had  the  privilege  to  login  another  pro- 
cess. 
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These  checks  are  a waste  of  time,  however,  because  the  hardcore  sub- 
routine must  make  these  checks  anyway  and  returns  appropriate  status 
codes.  A user  can  easily  write  his  own  delete  command  that  makes  no 
checks  before  calling  hardcore. 

When  testing  security  controls  it  is  essential  that  the  controls 
tested  are  invoked  by  direct  calls  to  the  most  primitive  functions 
available  to  the  user  (i.e.,  calls  to  hardcore  entries).  Only  in  tnis 
way  is  the  security  of  the  "system"  actually  being  tested.  If  one 
wanted  to  try  to  see  if  it  was  possible  to  delete  a segment  with  no 
access  permission  he  would  eventually  write  a program  to  call  the 
hardcore  delete  entry  directly  rather  than  give  up  when  the  user  level 
delete  command  refused  to  do  it. 

It  may  often  be  very  convenient  for  higher  level  routines  to  make 
certain  cnecks  before  calling  the  hardcore  primitives,  but  if  only  the 
higher  level  entries  are  called  during  testing  then  there  will  be  some 
primitive  controls  that  are  never  exercised. 

In  most  of  the  tests  described  within  this  report,  user  level 
system  software  is  bypassed  if  a security  related  function  is  being 
invoked  and  if  it  is  possible  ior  the  user  himself  to  bypass  the  sys- 
tem software.  Since  all  commands  are  user  level  routines,  many  com- 
mands that  are  used  to  test  security  controls  must  be  rewritten  for 
the  test  procedures.  Some  subroutines  also  have  to  be  rewritten. 

System  Processes 

There  is  one  consequence  of  testing  only  the  most  primitive  func- 
tions that  relates  to  the  Trojan  Horse  problem  [5].  Throughout  the 
course  of  the  Design  Analysis  it  was  assumed  that  procedures  within 
the  security  perimeter  contained  no  Trojan  Horses,  Trojan  Horses  out- 
side the  security  perimeter  in  user  level  software,  even  if  provided 
as  part  of  the  standard  system,  could  not  violate  security.  Thus,  no 
tests  of  user  level  software  are  necessary. 

In  the  case  of  system  processes,  which  can  be  considered  to  lie 
in  the  security  perimeter,  the  situation  is  quite  different.  A Trojan 
Horse  in  what  is  normally  a user  level  command,  when  executed  by  a 
system  process,  could  result  in  disaster.  This  problem  is  eliminated 
in  a validated  system  because  all  system  functions  that  can  have  an 
effect  on  security  are  included  within  the  kernel  and  do  not  depend  on 
any  software  outside  the  kernel.  For  the  enhanced  Multics,  such  iso- 
lation is  not  feasible. 

An  example  of  a system  process  is  the  System  Security  Administra- 
tor (SSA)  process.  The  SSA  is  given  a process  with  privileges  that 
allow  him  to  change  access  classes  of  directories.  A Trojan  Horse  in 
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the  SSA  command  to  set  the  access  class  of  a directory  can  change  the 
string  "secret"  to  "unclassified"  and  thereby  underclassify  a directo- 
ry. In  fact,  a Trojan  Horse  in  any  of  the  commands  available  to  the 
SSA,  whether  the  command  is  security  related  or  not,  can  potentially 
cause  considerable  damage  when  executed  in  a process  having  special 
privileges.  In  order  to  prevent  this  occurrence,  the  SSA  is  re- 
stricted to  using  only  a small  subset  of  specified  commands,  and  these 
commands,  though  they  may  be  the  same  as  those  generally  available  to 
users  in  an  unprivileged  mode,  must  be  tested  for  proper  functioning 
without  regard  to  whether  they  are  the  "most  primitive".  In  fact,  it 
is  more  important  to  check  the  highest  level  commands  available  to  the 
SSA  than  any  of  the  more  primitive  functions. 


Auditing 


A validated  secure  system  is  secure  whether  auditing  takes  place 
or  not.  The  only  value  of  auditing  in  such  a system  is  in  maintaining 
an  accountability  of  access  to  controlled  data  for  record  keeping. 

In  an  unvalidated  system,  like  the  enhanced  Multics,  auditing  is  also 
used  as  an  aid  to  detecting  possible  security  breaches.  Auditing  in 
this  case  can  be  viewed  as  a "catch  all"  in  that  it  has  a small  chance 
to  detect  penetration  attempts  that  may  have  been  allowed  due  to  bugs 
or  omissions  in  the  security  controls.  In  addition,  it  may  be  relied 
upon  to  detect  penetration  attempts  that  may  not  have  been  specifical- 
ly covered  in  the  design  of  the  security  controls  due  to  the  difficul- 
ty of  implementation.  An  example  of  the  latter  is  the  case  of  message 
segment  overflow,  where  the  "message  segment  full"  condition  can  be 
used  by  a Trojan  Horse  to  transmit  one  bit  of  information.  During 
normal  operation  this  condition  should  occur  only  infrequently  Tor  a 
given  user.  By  auditing  this  condition  the  attempted  passage  of  many 
bits  by  this  means  is  detectable.  It  should  be  noted,  however,  that 
only  a very  small  percentage  of  all  penetrations  can  ever  be  detected 
by  auditing  --  if  a person  is  clever  enough  to  penetrate  the  system  he 
can  probably  cover  his  tracks  by  erasing  any  audit  trails  that  might 
have  been  created. 


As  stated  earlier,  the  main  justification  for  permitting  an 
unvalidated  two  level  system  to  operate  at  the  AFDSC  was  that  the  us- 
ers of  the  AFDSC  are  assumed  to  be  basically  trustworthy.  Within  such 
an  environment,  auditing  may  only  detect  the  less  sophisticated  (ei- 
ther unintentional^  or  intentional)  penetration  attempts  by  AFDSC 


'That  is,  as  far  as  the  security  of  the  system  is  concerned.  There 
are  other  reasons  for  auditing,  such  as  monitoring  of  performance  and 
recording  of  vital  statistics. 

^An  unintentional  penetration  on  the  part  of  the  user  is  one  that 
occurs  accidentally  or  via  a Trojan  Horse  placed  by  someone  else. 
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users.  The  assumption  is  that  a benign  user  will  not  go  to  great  ef- 
forts to  develop  a highly  sophisticated  attack. 


It  is  important  to  be  aware  that  auditing  is  only  useful  if  the 
person  or  program  examining  the  audit  trail  is  able  to  sort  out  mean- 
ingful statistics.  An  example  of  a penetration  attempt  for  which  aud- 
iting may  be  useful,  and  which  the  security  controls  do  not  cover,  is 
the  guessing  of  another  user's  password.  If  every  rejected  login  is 
audited,  it  will  be  obvious  from  the  audit  trail,  before  too  long, 
that  someone  is  making  such  attempts.  The  individual  examining  the 
audit  trail  must  be  able  to  distinguish  this  penetration  attempt  from 
the  normal  "accidental"  illegal  logins  that  users  often  make. 

Auditing  is  explicitly  tested  by  performing  a specific  set  of  op- 
erations that  invoke  the  audit  mechanism.  An  examination  of  the  audit 
log  tnen  indicates  whether  the  operations  are  properly  recorded. 


BASIC  ASSUMPTIONS 

Complete  exhaustive  checkout  of  all  the  security  controls  in  any 
system  is  impossible  and  usually  unnecessary.  (Of  course  testing  or 
checkout  is  theoretically  unnecessary  in  a validated  system.)  A per- 
fect test  system  is  aware  of  the  details  of  the  system  design  and  only 
tests  each  node  or  decision  point  in  the  system  once,  in  a manner  sim- 
ilar to  checking  out  hardware  logic.  With  precise  implementation  de- 
tails lacking,  assumptions  must  be  made  regarding  this  system  struc- 
ture so  that  a vast  number  of  tests  are  not  required.  At  the  same 
time  one  must  be  wary  of  making  too  many  assumptions  and  thus  creating 
an  incomplete  test  system,  particularly  since  the  implementation  de- 
tails may  change  in  the  future. 


The  security  test  system  described  in  this  report  makes  few  as- 
sumptions about  the  internal  structure  of  the  security  controls.  The 
test  procedures  should  be  useful  for  all  future  system  updates,  possi- 
bly implementing  a new  or  modified  design.  A future  system  update 
must  not  render  the  test  system  incomplete. 

The  paragraphs  below  discuss  the  various  types  of  assumptions  one 
might  make  about  the  design  of  the  security  controls,  and  give  reasons 
why  these  assumptions  have  or  have  not  been  made  with  regard  to  the 
test  procedures. 


Centralization  of  Controls 


The  most  obvious  assumption  is  on  the  centralization  of  the  most 
basic  security  controls.  The  definition  of  access  class  used  in  the 
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AFDSC  system  has  been  given  on  page  12.  In  a completely  generalized 
secure  system,  which  is  the  ultimate  goal  for  Multics,  the  actual 
structure  of  this  access  class  is  a system  parameter  tnat  can  vary 
from  one  installation  to  the  next.  For  any  particular  access  class 
scheme,  definitions  must  be  made  to  allow  access  classes  or  authoriza- 
tions to  be  compared  with  one  another.  The  terms  "less  than",  "equal 
to",  etc.,  were  defined  on  page  13  for  the  military  classification  sys- 
tem. Since  comparison  of  access  classes  is  more  complex  than  just  a 
single  numeric  compare,  and  since  the  comparison  algorithm  may  be  in- 
stallation-defined, one  would  expect  there  to  be  a single  routine  that 
is  called  to  implement  the  comparison  of  access  classes.  It  would 
also  be  consistent  with  Multics  philosophy  to  assume  that  all  instanc- 
es of  access  class  comparison  or  testing  are  handled  by  the  same  cen- 
tralized procedures. 

Tnis  assumption  may  not  be  completely  correct,  however.  Although 
most  of  the  checks  are  made  by  a single  subroutine,  efficiency,  in 
certain  circumstances,  may  dictate  that  the  checks  be  explicitly  made 
elsewhere.  This  may  be  particularly  true  because  the  security  checks 
are  often  placed  at  the  lowest  levels  of  the  operating  system.  Thus, 
it  is  necessary  to  test  that  the  checks  are  made  properly  everywhere 
the  checks  are  expected  to  be. 

One  can  still  make  certain  assumptions,  however,  to  simplify  the 
testing.  These  assumptions  can  be  best  described  by  an  example. 

Using  the  definitions  of  tne  relationsnips  between  access  classes  giv- 
en on  page  13,  the  PL/I  code  for  determining  access  to  segments  would 
most  probably  look  similar  to  this: 

if  (authorization. level  < access_class. level ) or 

not  ( (authorization. category  and  access_class. category ) = 
access_c  lass. category) 
then  access_mode  = null 

else  if  (authorization. level  = access__class. level ) and 

(authorization. category  = access_class. category ) 
then  access_mode  = full  ACL 
else  access_mode  = ACL  minus  "write" 

We  assume  that  it  is  only  necessary  to  check  that  each  of  the  opera- 
tions in  the  statements  above  is  performed  properly.  For  example,  a 
typographical  error,  such  as  ">"  appearing  in  place  of  "<"  should  be 
detectable.  It  is  not  necessary  to  check  every  possible  combination 
of  level  and  category  if  it  can  be  assumed  that  the  code  used  to  im- 
plement the  check  is  similar  to  that  above.  That  is,  if  it  works  for 
authorization  level  3 and  access  class  level  it  can  be  assumed  to 
work  in  all  cases  where  authorization  is  less  than  access  class. 

Of  course,  one  could  always  create  some  strange  algorithm  that 
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yields  right  answers  for  all  combinations  of  levels  except  one  in  par- 
ticular. However,  the  billions  of  possible  category  set  and  level 
combinations  could  never  all  be  tested.  We  must  assume  that  we  have 
"benign  system  programmers"  who  make  reasonable  attempts  to  create 
correct  programs.  We  can  only  test  for  accidental  omissions  or  er- 
rors. 

Since  category  checks  are  quite  different  from  level  checks  (even 
though  both  checks  may  be  combined  into  one  PL/ I statement)  the  test 
procedures  are  designed  to  test  levels  independently  of  categories 
with  respect  to  each  of  the  areas  tested.  The  level  tests  are  usually 
made  with  null  or  constant  category  sets,  and  the  category  tests  are 
all  made  at  a single  level.  In  this  way,  system  bugs  are  much  easier 
to  trace  down  and  the  test  procedures  are  more  straightforward,  though 
perhaps  somewhat  more  time  consuming. 

Centralization  of  Functions 

There  are  various  "passive"  functions  associated  with  the  securi- 
ty controls  that  are  repeatedly  exercised  within  the  test  procedures. 

A passive  function  is  one  that  is  used  to  check  on  the  state  of  some- 
thing or  to  return  a value  but  does  not  otherwise  effect  any  securi- 
ty-related operation.  An  assumption  must  be  made  regarding  the  be- 
lievability  of  values  returned  by  these  passive  system  functions. 

For  example,  there  is  a subroutine,  called  hcs_$get_access_class , 
that  returns  the  access  class  of  any  segment.  This  function  must  be 
called  several  times  during  the  security  test  procedures.  If  the  ac- 
cess class  returned  by  this  function  is  not  believed,  a long  and  ardu- 
ous sequence  of  multiple  manual  logins  must  be  performed  in  order  to 
infer  the  access  class  of  a segment.  Alternatively,  the  program  wish- 
ing to  get  the  access  class  of  a segment  can  be  run  in  a more  privi- 
leged state  and  read  the  information  out  of  the  directory  by  itself. 

Both  methods  are  unsatisfactory. 

If,  on  the  other  hand,  one  can  make  the  assumption  that  the  same 
primitive  is  always  invoked  wnenever  the  access  class  of  a segment  is 
required,  it  is  only  necessary  to  check  that  this  primitive  works 
once.  Furthermore,  in  this  particular  example,  one  can  test 
hcs_$get_access_class  merely  by  requesting  the  access  class  of  various 
segments  of  known  access  classes  that  have  been  previously  set  up. 

Another  function  belonging  to  this  group  is  one  that  converts  the 
character  string  representation  of  an  authorization  to  the  internal 
binary  representation,  and  vice  versa.  This  innocuous  routine  does 
not  even  need  to  run  in  a privileged  state  — any  user  can  replace  the 
system  version  of  this  routine  with  his  own.  However,  if  this  routine 
works  incorrectly  (e.g.  , returning  the  string  "top_secret"  when  "se- 
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cret"  was  specified)  there  could  be  disaster,  specifically  in  the  ad- 
ministrative areas  and  system  processes  as  discussed  earlier.  We  must 
assume  that  this  same  routine  is  invoked  every  time  the  character 
string-to-binary  conversion  is  required.  We  only  need  to  test  this 
routine  once. 

There  are  other  functions  performed  repeatedly  that  the  test 
procedures  must  believe.  These  will  be  discussed  as  necessary  in  the 
following  section.  All  such  functions  whose  values  are  generally  be- 
lieved are  explicitly  tested. 


SUPPORT  SOFTWARE 

Tnis  subsection  discusses  various  support  programs  used  during 
the  security  test  procedures.  These  programs  are  discussed  separately 
from  the  tests  because  they  are  generally  called  several  times  in  sev- 
eral tests,  and  thus  do  not  belong  to  any  specific  group  of  tests. 

Authorization  Tester 


The  authorization  tester  is  a program  that  determines  the  author- 
ization level  and  category  set  of  the  current  process  (in  terms  of  ac- 
cess rights)  and  compares  this  authorization  to  the  authorization  that 
the  system  thinks  the  current  process  has.  It  prints  the  current  au- 
thorization on  the  terminal. 

A special  directory  is  set  up  during  test  environment  initializa- 
tion (see  Figure  2 on  page  31)  that  contains  segments  of  various  ac- 
cess classes.  The  authorization  tester  reads  segments  of  successively 
higher  levels  and  of  different  category  sets.  The  highest  level  is 
calculated  and  all  the  categories  accessible  are  or'ed  together  to  de- 
termine the  process  authorization.  The  authorization  tester  makes 
sure  that  the  authorization  returned  by  a eail  to 

hcs_$get_authorization  (the  system  primitive  that  returns  the  current 
authorization)  is  the  same  as  the  process  authorization  that  has  been 
determined  from  access  privileges. 

The  authorization  tester  does  not  comprise  a test  by  itself,  but 
is  used  as  a utility  during  various  tests.  Its  name  is 
"authorization_tester"  and  it  is  available  as  a user  callable  command 
that  prints  the  authorization  or  error  message  on  the  terminal. 

Access  Routines 


The  authorization  tester  determines  the  current  authorization  by 
accessing  known  segments  of  various  access  classes.  In  an  analogous 
manner,  there  is  a program  that  attempts  to  access  a given  segment  in 
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different  modes  (read,  execute,  write)  to  determine  the  type  of  access 
available  to  that  segment  by  the  current  process.  This  test  provides 
information  as  to  whether  the  access  class  of  the  segment  is  "less 
than",  "equal  to",  "greater  than"  or  "isolated  from"  the  current  au- 
thorization. There  is  another  program  that  performs  the  same  function 
for  directories.  These  programs  are  in  the  form  of  subroutines  with 
the  names  "try_reference_"  and  "try_dir_reference_". 


SECTION  III 
DESCRIPTION  OF  TESTS 

This  section  describes  the  individual  tests  that  comprise  the  se- 
curity test  procedures.  The  tests  are  grouped  by  the  area  of  tne  sys- 
tem that  is  being  tested.  The  discussion  for  each  group  is  preceded 
by  a brief  description  of  the  design  of  the  Multics  security  controls 
to  be  tested.  Some  of  the  tests,  designated  as  scripts,  are  made  man- 
ually by  an  operator,  and  others  are  done  completely  by  software.  The 
tests  are  discussed  in  this  section  in  sufficient  detail  for  an  under- 
standing of  the  testing  process.  The  complete  scripts  are  contained 
in  Appendix  II,  and  program  listings  in  Appendix  IV. 

Each  test  is  given  an  identifier  consisting  of  a series  name  of 
tnree  characters  followed  by  a test  number  (e.g.  PAA-5).  This  identi- 
fier can  be  used  to  reference  the  corresponding  script  in  Appendix  II. 
The  discussion  along  with  each  script  indicates  the  correspondence  be- 
tween program  modules  and  test  numbers  for  those  tests  performed  en- 
tirely by  software. 


TEST  ENVIRONMENT 

In  order  to  simplify  the  testing  process,  a test  environment  is 
defined  that  consists  of  a set  of  users,  projects,  directories,  etc. 
that  permanently  reside  in  the  system.  This  environment  need  be  ini- 
tialized only  once  per  installation.  If  the  tests  function  properly, 
data  bases  defining  the  environment  will  not  be  modified.  A system 
bug,  however,  could  possibly  change  something  and  require  reinitiali- 
zation of  the  environment. 

The  components  of  the  test  environment  are  users,  projects,  ter- 
minals, I/O  devices,  and  directories.  Each  of  these  is  discussed  be- 
low. Appendix  I contains  detailed  instructions  for  setting  up  the  en- 
vi ronment . 

Users.  Projects  and  Terminals 

These  three  components  of  the  test  environment  are  initialized  by 
the  System  Administrator  (SA)  and  the  System  Security  Administrator 
(SSA).  The  actual  names  of  the  users,  projects  and  terminals  need 
not,  of  course,  be  the  same  as  those  specified  in  this  section,  pro- 
vided those  the  same  names  are  consistently  used  throughout  all  the 
tests. 
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There  are  four  tables  maintained  by  the  system  that  are  not  nor- 
mally accessible  to  the  user.  These  tables  contain  attributes  of  us- 
ers, projects  and  terminals.  A discussion  of  the  security  related 
function  of  each  follows: 

1.  Person  Name  Table  ( PNT) 

Tnis  is  a per  system  table  that  contains  an  entry  for  each 
person  (personid)  on  the  system.  This  table  specifies  the  maxi- 
mum authorization  of  each  user  on  the  system.  This  maximum  au- 
thorization is  normally  the  same  as  the  person's  own  security 
clearance . 

2.  System  Administration  Table  (SAT) 

This  is  a per  system  table  that  contains  an  entry  for  each 
project  (projectid)  on  the  system.  Each  project  has  a maximum 
authorization  assigned  to  it  that  reflects  the  maximum  access 
class  of  the  work  being  performed  on  that  project. 

3.  Project  Definition  Table  (PDT) 

This  is  a per  project  table  that  contains  an  entry  for  each 
user  that  may  login  under  that  project.  For  each  user  in  a pro- 
ject, this  table  specifies  the  maximum  authorization  that  any 
process  for  this  user  may  have  when  running  under  that  project. 

k.  Channel  Definition  Taole  (CDT) 

This  is  a per  system  table  that  contains,  among  other 
things,  an  entry  for  each  channel  known  to  the  system.  The  AFDSC 
Multics  operates  only  with  hardwired  terminals  (or  equivalently, 
remote  terminals  over  encrypted  lines),  so  that  each  terminal  is 
known  to  be  attached  to  a specific  physical  channel.  The  channel 
number  uniquely  identifies  a terminal.  The  CDT  contains  the  au- 
thorization of  each  terminal,  which  is  determined  by  the  physical 
access  to  that  terminal:  a secret  terminal  is  located  in  a secret 
controlled  area,  etc. 

The  tables  discussed  above  allow  a given  user  to  work  on  several 
projects  of  different  authorizations.  If  the  user's  security  clear- 
ance is  stored  in  the  PNT  as  a maximum  authorization,  addition  or  re- 
classification of  a project  is  independent  of  the  security  clearance 
of  its  users.  There  is  no  danger  that  a project  administrator  (who 
can  set  the  authorization  of  each  user  in  his  PDT)  will  allow  a user 
to  run  at  an  authorization  greater  than  that  specified  in  the  PNT. 


Below  are  step-by-step  instructions  for  the  procedures  required 
to  initialize  values  in  tnese  four  tables  for  the  users,  projects  and 
terminals  used  in  the  tests. 

1.  Create  users  and  projects. 

The  System  Administrator  (SA)  creates  five  dummy  projects  in  the 
SAT:  pi,  p2,  p3,  p4,  and  p5.  There  is  a single  project  administra- 
tor assigned  to  all  these  projects.  The  SA  also  inserts  seven  users 
in  the  PNT:  ul,  u2,  u3,  u4,  u5,  u6  and  u7. 

2.  Assign  authorizations. 

The  SSA  assigns  the  following  authorizations  to  each  user  and 
project : 


pi : 

secret 

ul : 

conf idential 

p2 : 

conf idential 

u2 : 

top  secret 

P3  = 

confidential , 1 

,2, 3, 4, 6, 7 

u3: 

secret 

p4 : 

conf idential , 4 , 

.5,6 

u4 : 

confidential, 1 ,3, 4, 5, 6, 7 

P5: 

system_high 

u5: 
u6 : 
u7: 

confidential ,1,3>4,5,6,7 

system_high 

system_high 

Five  terminals  are  used.  The  SSA  sets  the  authorizations  of  these 
terminals  in  the  CDT  as  follows: 

1 1 : confidential 
t2:  top  secret 
t3:  confidential , 1 , 3 » 5 , 6 ,7 
t4:  confidential , 1 , 2, 3 , 4 , 5 , 6 ,7 
t5:  system_high 

3.  Assign  authorizations  within  projects. 

The  project  administrator  logs  in  under  each  of  the  five  projects 
and  names  all  five  users  under  each  project.  For  pi  and  p3,  the 
seven  users  are  assigned  authorizations  within  those  projects  as 
follows : 


ul : secret 

u2:  top  secret 

u3:  unclassified 

u4:  confidential, 1 ,2, 4, 5, 6, 7 

u5:  confidential, 1 ,2, 4, 5, 6, 7 

u6:  none 

u7 : none 
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For  p2,  p4  and  p5,  no  specific  authorizations  are  assigned,  thus 
letting  the  default  take  over. 

4.  Forced  generate _password  option  for  u 2. 

There  is  a flag  that  can  be  set  for  specific  users  by  the  SA  that 
prevents  a user  from  defining  his  own  passwords.  Instead,  the  user 
is  forced  to  use  passwords  generated  by  the  system.  In  order  to 
later  test  this  flag,  the  SA  sets  this  flag  for  u2. 

As  a result  of  the  above  five  steps,  we  now  have  the  following 
authorization  values  in  each  of  the  tables. 

PNT  PDT  for  pi  4 p3  SAT  CDT 


u1  = C 
u2=T 
u3=S 

u4=C,1,3,4,5,6,7 

u5=C,1,3,4,5,6,7 

u6=system_high 

u7=system_high 


u1  = S 
u2=T 
u3=U 

u4=C,1,2,4,5,6, 
u5=C, 1 ,2, 4, 5, 6, 
ub=none 
u7=none 


p1=S 

p2=C 

p3=C, 1 ,2, 3, 4, 6, 

p4=C,4,5,6 

p5=system_high 


t1  = C 
t2=T 

1 3= C, 1,3, 5, 6, 7 
t4=C, 1 ,2, 3, 4, 5, 6, 7 
t5=system_high 


Directories  and  Segments 


In  Section  II  it  was  stated  that  some  of  the  test  procedures  re- 
quire special  directories  and  segments  that  are  set  up  beforehand. 
These  "subtrees"  are  part  of  the  static  test  environment  and  are  cre- 
ated by  a series  of  special  commands  during  the  test  environment  ini- 
tialization. If  tne  tests  function  properly,  these  subtrees  should 
remain  intact,  since  no  modifications  are  made  during  the  test  proce- 
dures. The  test  procedures  are  designed  so  that  aborting  during  any 
of  the  tests  will  not  leave  these  directories  in  an  unusable  state. 
Even  if  a security  related  bug  is  found  during  the  testing,  these  di- 
rectories should  not  be  adversely  affected.  However,  to  protect 
against  unforeseen  problems,  this  portion  of  the  test  environment 
should  be  reinitialized  if  any  system  bug  is  found  by  the  tests. 

Five  directories  are  required.  Three  are  referenced  for  the  di- 
rectory, segment,  and  System  Security  Administrator  tests,  one  is  used 
by  the  authorization  tester,  and  one  contains  files  referenced  during 
the  I/O  tests.  Each  of  these  directories  contains  subdirectories  and 
segments  of  various  access  classes.  Creation  of  these  directories 
manually  is  a rather  tedious  process,  since  the  user  must  repeatedly 
login  (or  new_proc)  at  the  different  access  classes  to  create  segments 
residing  within  the  upgraded  directories.  Alternatively,  the  creator 
of  these  directories  could  perform  the  whole  process  at  one  level  of 
authorization  (unclassified),  and  then  exercise  system  privilege  to 
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upgrade  the  directories  and  segments  to  their  proper  access  classes. 
This  latter  approach  is  unattractive  since  the  operation  is  basically 
not  a privileged  one. 
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Fortunately,  Multics  provides  a mechanism  whereby  a certain  pro- 
cedure or  set  of  commands,  called  a start_up.ec,  can  be  executed  au- 
tomatically at  the  beginning  of  a process.  Given  the  capability  for 
destroying  the  current  process  and  creating  a new  one  of  a different 
authorization,  most  of  the  procedure  can  be  automated.  The  exact  de- 
tails are  explained  in  Appendix  I.  The  manner  in  which  the  five  basic 
directories  are  created  is  not  relevant  to  the  discussion  below. 

1.  Directory  for  authorization_tester . 

This  directory  is  shown  in  Figure  2.  In  the  figure,  there  is  one 
upgraded  directory  (and  contained  segment)  for  each  level  and  each 
category  within  system_high.  Thus,  in  an  installation  that  uses  5 
levels  and  8 categories  there  would  be  13  directories.  Each  of  the 
"level"  directories  is  classified  at  the  appropriate  level  with  a 
null  category  set.  The  access  class  of  each  of  the  "category"  di- 
rectories has  one  category  bit  set  and  level  number  zero.  The  name 
of  each  directory  is  related  to  the  access  class,  so  that  the 
authorization_tester  can  reference  the  proper  directory  without  hav- 
ing to  rely  on  any  special  primitives  tnat  return  access  classes  of 
objects.  If  for  some  reason  a directory  of  some  access  class  within 
system_high  is  missing,  an  error  message  will  be  generated  when  tne 
authorization  tester  attempts  to  access  the  missing  directory. 


Figure  2.  Directory  for  Authorization  Tester 
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2.  Directory  for  segment  security  controls  tests. 

This  directory  is  illustrated  in  Figure  3.  The  SEG_TEST  directory 
is  at  system_low,  and  each  of  the  subdirectories  beneath  is  at  some 
access  class  whose  category  bits  and  level  number  bear  a specific 
relation  to  the  authorization  at  which  the  segment  access  tests  are 
to  be  run.  The  figure  shows  specific  access  classes  of  the  six  up- 
graded directories  D1  through  D6  as  an  example,  assuming  the  tests 
will  be  run  at  the  authorization  secret ,c 1 ,c2.  The  directories  Dirt 
and  segments  SEG  are  classified  the  same  as  their  parent.  In  Appen- 
dix I the  access  classes  of  the  six  directories  are  specified  as  ar- 
guments to  the  command  that  creates  them.  See  the  specific  discus- 
sion of  the  segment  security  controls  test  procedures  on  page  52. 


Figure  3. 


Directory  for  Segment  Security  Controls  Tests 


3.  Directory  for  directory  security  controls  tests. 

The  directory  for  the  directory  tests  as  illustrated  in  Figure  4 has 
almost  the  same  structure  as  the  directory  for  the  segment  tests. 

The  only  difference  is  that  the  segment  in  each  directory  is  con- 
tained directly  within  the  upgraded  directory  rather  than  within  a 
subdirectory.  See  the  procedures  for  directory  security  controls 
tests  on  page  54. 

4.  Directory  for  I/O  tests. 

The  directory  for  the  I/O  tests,  IO_TEST,  as  illustrated  in  Figure  5 
is  at  system  low  and  contains  segments  and  directories  used  in  the 


Figure  4.  Directory  for  Directory  Security  Controls  Tests 


I/O  tests.  When  the  I/O  tests  are  performed  the  user's  working  di- 
rectory is  IO_TEST.  Certain  tests  require  segments  of  a higher  ac- 
cess class.  These  segments  reside  in  directories  whose  parent  is 
IO_Tfc.ST.  See  the  procedures  for  the  I/O  tests  on  page  61. 


5.  Directory  for  System  Security  Administrator  tests. 

Figure  6 shows  the  directory  required  for  the  SSA  tests.  The  direc- 
tory S3A_TEST  is  at  some  access  class  above  system_low,  and  the  con- 
tained directory  and  two  segments  are  at  the  same  access  class.  The 
segment  named  MSEG  is  a message  segment  (see  the  discussion  of  mes- 
sage segments  in  the  tests  of  communication  between  processes  on 
page  61).  The  two  segments  and  the  directory  are  empty. 


I/O  Devices 


Trie  initialization  of  I/O  devices  is  performed  by  defining  device 
classes  having  specific  values  of  certain  parameters  for  the  required 
devices.  Before  each  test  of  a device  is  made,  the  device  must  be 
logged  in  and  assigned  to  the  proper  queue  group  and  device  class. 

The  table  below  lists  the  values  of  the  relevant  parameters  required 
for  the  I/O  device  classes  to  be  defined. 
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device 

name 

min  class 

max  class 

min  banner 

card 

reader 

crd 

(none) 

S,c  1 ,c2 

(none) 

card 

reader 

crd 

(none) 

U 

( none ) 

card 

punch 

punch 

C,c  1 ,c2 

S,c1 ,c2,c3,c4 

R,c1,c2,c3 

line 

printer 

prt  1 

C,c 1 ,c2 

S,c 1 ,c2,c3,c4 

R,c  1 ,c2,c3 

line 

printer 

prt2 

S,c 1 ,c2,c3, 

,c4  T,c 1 ,c2,c3,c4,c5 

T,c1  ,c2,c3,c4 

tape 

drive 

tape 

C,c1  ,c2 

C,c  1 ,c2 

(none) 

PASSWORD  DISTRIBUTION 
Design  Description 

The  password  distribution  mechanism  in  Multics  is  designed  to 
provi  le  the  system  with  positive  proof  of  the  identities  of  users. 
Passwords  are  initially  assigned  to  users  by  the  system  administrator, 
and  thereafter  a user  may  change  his  password  at  any  time.  Depending 
on  system  parameters,  a user's  request  to  change  his  password  may  in- 
voke a system  procedure  to  generate  a random  pronounceable  word  [7], 
or  tne  user  may  be  allowed  to  pick  his  own  new  password. 

At  each  login,  the  user  must  type  his  current  password  on  the 
line  following  the  login  line,  and  the  system  verifies  that  the  pass- 
word is  correct.  If  the  user  wishes  to  change  his  password,  he  indi- 
cates this  by  an  option  on  the  login  line.  The  user  may  elect  to 
change  his  password  himself,  or  have  the  system  generate  one  for  him. 
After  the  original  password  has  been  verified,  the  user's  new  password 
is  entered  or  generated,  and  this  new  password  must  be  used  in  subse- 
quent logins. 

Test  Procedures 


This  series  of  tests  checks  that  the  password  distribution  and 
validation  mechanism  works  properly.  The  tests  are  performed  by  two 
users,  ul  and  u2,  both  under  project  pi. 


PDS-1:  Initial  password. 


Tne  3A  nas  a command  that  sets  a password  to  a given  value  for  a 
user.  This  command  is  used  to  assign  an  initial  password  to  the 
user  when  the  user  is  first  registered  on  the  system,  or  at  other 
times  such  as  when  the  user  forgets  his  password  or  when  it  is 
suspected  that  the  user's  password  may  have  been  compromised  and  the 


user  himself  cannot  be  located  to  change  the 
be  used  to  lock  out  a user  (though  there  are 
For  tnis  test  the  3A  logs  in  and  changes  the 


password.  It  can  also 
other  ways  to  do  that), 
password  of  ul.  Then 
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ul  attempts  to  login  with  his  old  password,  and  this  attempt  should 

fail. 


PDS-2:  Initial  password  change. 

This  time  the  user  logs  in  correctly  and  changes  his  password.  This 
test  checks  that  the  same  initial  password  as  set  in  PDS-1  is  still 
in  force  until  explicitly  changed  by  the  user.  Another  feature  of 
password  control  that  is  checked  by  this  test  is  the  notification  to 
the  user  when  his  password  was  incorrectly  used  on  preceding  logins. 

PDS-3:  Incorrect  password  entry. 

This  test  checks  that  the  password  was  actually  changed  by  PDS-2. 

The  user  attempts  to  login,  using  the  initial  password,  but  his  at- 
tempt should  be  rejected  until  he  types  the  new  password. 

PDG-4:  Generate  password. 

Multics  has  two  password  control  options  that  the  user  may  specify 
4 when  he  logs  in.  The  cnange_password  option  allows  the  user  to 

specify  a new  password  for  subsequent  logins.  The  generate_password 
option  generates  a random  password  for  the  user,  and  allows  the  user 
to  specify  this  random  password  as  his  new  password.  Normally,  the 
user  has  the  option  of  using  either  of  these  two  methods  for  select- 
ing a new  password.  However,  there  is  a parameter  can  be  set  that 
requires  all  password  changes  to  be  made  with  the  generate_password 
option  rather  than  change_p as sword . Installations  such  as  AFDSC  set 
this  parameter  because  users  cannot  generally  be  trusted  to  pick  a 
password  sufficiently  difficult  for  others  to  guess.  For  PDS-4, 
user  ul  uses  the  generate_password  option,  but  chooses  to  ignore  the 
generated  password  by  entering  a different  word.  Since  user  ul  does 
not  have  the  generate_password  requirement,  this  new  password  is  ac- 
cepted. 

PDS-5:  Test  generated  password. 

As  in  PDS-3,  the  user  now  logs  in  again  and  tries  his  old  password 
to  verify  that  PDS-4  actually  changed  his  password. 

PDS-6:  Forced  generate  password. 

This  test  is  very  similar  to  PDS-4,  except  that  this  time  a differ- 
ent user,  u2,  uses  the  generate_password  option.  Since  u2  is  re- 
quired to  use  the  generated  password,  his  attempt  to  ignore  the  gen- 
erated password  should  fail. 


PDS-7:  Generate  password  required. 

The  final  test  checks  that  the  change_password  option  is  not  permit- 
ted for  u 2.  The  user  attempts  to  login  with  the  change_password  op- 
tion, but  the  system  should  refuse  to  accept  a new  password  from  the 
user. 


PROCESS  AUTHORIZATION  ASSIGNMENT 

Tnis  series  of  tests  is  designed  to  check  the  security  controls 
involved  in  determining  the  authorization  of  a process.  Since  proc- 
esses can  be  created  either  by  a login  or  at  some  other  time  at  the 
request  of  a user  (by  the  new_proc  command),  the  tests  first  focus  on 
all  the  login  controls  and  then  concentrate  on  the  new_proc  controls. 
Only  the  authorization  related  controls  are  tested.  It  is  assumed 
that  the  normal  login  controls  (password  validation,  etc.)  are  work- 
ing. 

Design  Description 

In  the  discussion  to  follow,  the  term  "userid"  refers  to  a spe- 
cific user  on  a specific  project.  The  userid  is  often  written  as 
"personid. project id" . 

tach  possible  userid  has  an  authorization  that  is  assigned  to  it. 
This  userid  authorization  is  the  minimum  of  the  values  in  the  SAT, 

PDT,  and  PNT  for  that  personid  and  projectid.  Ultimately,  we  are  con- 
cerned with  the  authorization  that  is  assigned  to  the  process  created 
for  a userid  at  login.  This  process  authorization  can  never  be  great- 
er than  the  userid  authorization. 

The  CDT  is  used  to  make  sure  that  no  terminal  transmits  data  of 
an  access  class  higher  than  that  of  the  terminal  authorization.  The 
actual  authorization  assigned  to  a process  for  a userid  is  then  fur- 
ther limited  by  the  authorization  of  the  terminal  to  which  the  user 
has  logged  in. 

The  user  may  select,  as  a login  option,  to  run  at  any  authoriza- 
tion less  than  or  equal  to  the  maximum  authorization  allowed  for  his 
process  as  determined  from  the  four  tables  above.  When  no  authoriza- 
tion is  specified  at  login,  a user-settable  default  becomes  the  au- 
thorization of  the  process.  If  no  default  is  specified  by  the  user, 
the  lowest  authorization  — unclassified  with  no  categories  — is 
used.  The  actual  authorization  of  the  process  is  stored  in  two  tables 
unalterable  for  the  life  of  the  process:  the  process  initialization 
table  and  the  process  data  segment.  The  user-settable  default  is 
probably  stored  in  the  PNT. 
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There  is  one  more  login  test  that  the  system  can  and  does  make. 
Since  terminals  are  in  controlled  areas,  a user  whose  security  author- 
ization is  less  than  that  of  a specific  termini.'  should  not  be  allowed 
to  use  that  terminal.  If  the  system  detects  that  the  authorization  in 
the  PNT  for  a specific  user  is  less  than  that  of  the  terminal  he  is 
logging  in  from,  a breach  of  physical  security  may  have  occurred  and 
the  machine  room  operator  is  notified. 

Only  in  this  latter  case  is  a message  actually  printed  to  the  op- 
erator. Other  illegal  logins  are  simply  rejected.  All  logins,  legal 
or  illegal,  are  audited  on  the  system  audit  trail. 

In  the  normal  Multics  environment  the  user  may  elect  to  create  a 
new  process  for  himself  and  destroy  the  old  one.  Creation  of  a new 
process  is  very  similar  to  logging  in,  and  thus,  in  the  AFDSC  system, 
some  of  the  login  tests  must  be  retried.  When  the  user  wants  a new 
process,  he  types  the  "new_proc"  command  and  can  optionally  select  a 
new  authorization  at  which  to  run.  The  system  must  then  validate  tne 
new  autnorization  in  a manner  identical  to  that  at  login.  In  the  case 
♦ of  an  abnormal  process  termination,  in  which  a new  process  is  automat- 

ically created,  the  authorization  of  the  new  process  is  the  same  as 
that  of  the  old. 

Every  time  a new  process  is  created,  either  at  login  or  new_proc, 
the  authorization  of  the  process  is  printed  on  the  terminal.  This 
printing  cannot  and  must  not  be  suppressed.  Not  only  is  it  important 
that  the  authorization  printed  is  actually  the  same  as  that  of  the 
process,  but  it  is  very  important  that  this  authorization  is  that  se- 
lected or  expected  by  the  user.  If  a process  of  a lower  authorization 
were  accidentally  created,  the  user  might  not  notice  the  printed  mes- 
sage (or  the  terminal  might  malfunction)  and  he  could  possibly  think 
he  was  running  at  the  higher  authorization.  He  might  then  input  clas- 
sified information  to  a process  of  a lower  authorization.  Even  though 
this  particular  malfunction  of  the  security  controls  does  not  create  a 
direct  compromise  situation,  it  is  dangerous  and  must  be  checked.  In 
addition,  a bug  in  the  controls  in  this  area  may  indicate  a possible 
bug  in  some  other  area  that  could  lead  to  compromise. 

i 

Test  Procedures 


Since  logins  cannot  be  controlled  by  user  software,  the  testing 
of  logins  must  be  mostly  a manual  procedure.  For  these  tests,  the 


O 

MITRE  has  developed  a minicomputer  based  Remote  Terminal  Emulator 
[8],  used  in  testing  performance  of  timesharing  systems,  that  can  emu- 
late a large  number  of  terminals.  One  can  prepare  scenarios  (such  as 


37 


values  in  the  PNT,  PDT,  3AT  and  CDT  as  set  up  by  the  SA  and  SSA  in  the 
test  environment  will  be  frequently  referred  to.  Consider  the  author- 
izations stored  in  these  four  tables.  For  a given  user,  project  and 
terminal  combination  there  are  many  possible  relational  combinations 
of  the  values  in  these  four  tables.  However,  it  is  only  necessary  to 
check  that  the  rule 

maximum  process  authorization  = min  (PNT,  PDT,  SAT,  CDT) 

holds  when  each  of  tnese  four  values  is  less  than  the  others.  Unfor- 
tunately there  is  no  direct  (and  believable)  way  to  determine  what 
iHultics  computes  as  the  maximum  process  authorization.  One  must  first 
try  to  login  at  a higher  authorization  than  this  maximum  to  see  if  he 
is  rejected;  then  a login  is  tried  at  the  maximum  process  authoriza- 
tion and  the  login  should  be  accepted. 

PAA-1  to  PAA-5:  Login  above  maximum. 

This  first  group  consists  of  five  logins.  Each  login  checks  that 
the  user  cannot  specify  a higher  process  authorization  than  the  max- 
imum as  determined  from  the  PNT,  SAT,  PDT,  and  CDT.  The  table  below 
outlines  the  five  logins  and  which  of  the  four  tables  are  being 
tested. 


test  for 
value  in 

user 

project 

selected 

terminal 

used 

auth. 

selected 

maximum  process 
authorization 

PAA-1 : 

PNT 

u 1 

Pi 

tl 

S 

C (rejected) 

PAA-2 : 

PDT 

u3 

Pi 

tl 

C 

U (rejected) 

PAA-3 : 

CDT 

u2 

Pi 

tl 

S 

C (rejected) 

PAA-4 : 

CDT 

ul 

Pi 

1 2 

none 

**  (see  below) 

PAA-5: 

SAT 

u2 

Pi 

t2 

T 

S (rejected) 

**  The  test  PAA-4  above  tests  the  additional  feature  that  the  opera- 
tor is  notified  when  the  value  in  the  PNT  is  less  than  the  value  in 
the  CDT  (breach  of  physical  security).  In  addition  to  rejecting  the 
login  attempt,  the  operator's  console  should  print  a message. 

PAA-6  to  PAA-9:  Login  at  maximum. 

Now,  a legal  authorization,  which  is  the  maximum  authorized,  is  se- 
lected on  each  of  four  logins  to  test  each  of  the  four  tables.  The 
following  table  summarizes  the  tests. 


those  for  logging  in)  for  the  emulator  that  duplicate  manual  input 
from  the  terminal.  It  may  therefore  be  feasible  to  use  the  emulator 
for  the  manual  procedures  described  in  this  section. 
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user 

project 

terminal 

authorization  selected 

PAA-6:  ul 

Pi 

tl 

C 

PAA-7 : u2 

Pi 

tl 

C 

PAA-8:  u3 

Pi 

tl 

U 

PAA-9 : u2 

Pi 

t2 

S 

The  authorization_tester  is  run  after  each  login  to  ascertain  the 
authorization  of  tne  new  process. 

PAA-10  to  PAA-12:  Login  below  maximum. 

It  is  necessary  to  check  that  the  user  can  specify  an  authorization 
that  is  lower  than  the  maximum  process  authorization.  PAA-10  checks 
that  a confidential  process  can  be  created  when  the  maximum  is  se- 
cret. PA A— 1 1 makes  sure  that  the  default  authorization  (when  none 
is  specified  by  the  user)  is  unclassified.  In  PAA-12,  the  user  logs 
in  and  sets  his  default  authorization  to  confidential.  He  then  logs 
out  and  logs  in  again,  this  time  not  specifying  an  authorization. 

His  default  of  confidential  should  be  used. 


authorization  process 


user 

project 

terminal 

selected 

authorization 

PAA-10: 

u2 

Pi 

t2 

C 

C 

PA A- 1 1 : 

ul 

Pi 

t2 

none 

U 

PAA-12: 

u2 

Pi 

t2 

none 

C 

The  authorization_tester  is  again  run  after  each  of  these  logins  to 
see  that  the  process  authorization  is  properly  set. 

PAA-13  and  PAA-14:  Login  at  default  authorization. 

Two  more  logins  check  that  the  PDT  default  authorizations  work  prop- 
erly. For  project  p2,  where  the  default  authorization  of  each  user 
was  not  set,  the  value  for  p2  in  the  SAT  should  become  the  default. 

authorization 

user  project  terminal  selected  result 


PAA-13:  u2  p2  t2  S rejected 

PAA-14:  u2  p2  t2  C C process 

PAA-15  to  PAA-18:  new_proc  authorization. 

The  new_proc  command  can  be  checked  in  a single  session  as  summar- 
ized in  the  four  tests  below.  It  is  assumed  that  the  authorization 
validation  is  the  same  on  new_proc  as  it  is  at  login.  Therefore,  it 
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is  only  necessary  to  test  that  the  controls  are  invoked  and  that  the 
selected  authorization  is  properly  passed  from  the  previous  process. 

PAA-15  begins  witn  the  user's  logging  in  at  secret  and  forcing  an 
abnormal  process  termination.  The  system  automatically  creates  a 
new  process  in  such  a case,  and  the  authorization  of  this  new  pro- 
cess (as  verified  by  the  authorization_tester ) should  also  be  se- 
cret . 

In  PAA-16  the  user,  still  running  the  secret  process,  manually  cre- 
ates a new  process  and  specifies  an  authorization  of  confidential. 
This  tests  that  the  user  is  able  to  downgrade  his  new  process  prop- 
erly. 

PAA-17  is  similar  to  PAA-16  except  that  this  time  the  user  attempts 
to  upgrade  his  process  from  confidential  to  secret. 

The  last  new_proc  test,  PA A— 1 8 , checks  that  the  user  is  not  allowed 
to  create  a process  above  his  maximum.  In  this  test  the  user  at- 
tempts to  new_proc  to  top  secret,  and  his  attempts  should  be  rejec- 
ted. The  rejection  in  this  last  test  is  due  to  the  user's  exceeding 
the  authorization  specified  for  p2  in  the  SAT.  It  is  assumed  that 
the  CDT,  PDT,  and  PNT  are  also  limiting  factors  as  they  were  for 
login.  No  further  checks  are  made  with  respect  to  these. 

user-terminal-  current  action  new  process 

project  authorization  performed  authorization 


PA A- 1 5 : u2  t2  pi 
PAA-16:  u2  t2  pi 
PAA-17:  u2  t2  pi 
PAA-18:  u2  t2  pi 


S 

S 

C 

S 


abnormal  term. 
new_proc  to  C 
new_proc  to  S 
new_proc  to  T 


S 

C 

S 

rejected 


In  PAA-18  a special  new_proc  command  is  used,  instead  of  the  stand- 
ard system  new_proc.  This  special  new _proc  operates  the  same  as  the 
system's  new_proc,  except  that  it  exercises  the  system  primitives  in 
ring  zero  by  making  no  checks  for  authorization  errors  in  the  user 
ring  as  might  be  made  by  the  system  new_proc  command. 


PAA-19  to  PAA-29:  Category  tests  at  login. 


Up  to  this  point,  the  security  controls  were  tested  only  with  re- 
spect to  levels  — null  category  sets  were  used.  It  is  necessary  to 
test  that  the  category  sets  are  handled  properly  in  each  of  the 
tests  PAA-1  through  PAA-18. 

Since  categories  are  only  partially  ordered,  several  possible  rela- 
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tionships  can  exist  between  two  category  sets  Cl  and'C2:^ 

Cl  "greater  than"  C2 

Cl  "equal  to"  C2 

Cl  "less  than"  C2 
or,  if  none  of  the  above: 

Cl  & C2  = null  (disjoint) 

Cl  Sc  C2  = not  null  (isolated  but  not  disjoint) 

The  maximum  process  authorization  defined  near  the  top  of  page  38 
should  be  properly  calculated  for  each  of  the  above  cases.  Since 
the  rule  specifies  calculation  of  a minimum,  and  the  minimum  is  cal- 
culated as  the  intersection  of  the  category  sets,  it  is  necessary  to 
determine  that  each  of  the  category  sets  (in  the  PNT,  SAT  etc.)  are 
included  in  this  calculation.  All  the  following  tests  are  made  at  a 
single  authorization,  confidential,  because  it  has  already  been  ver- 
ified that  levels  are  handled  properly. 

User  u4's  maximum  process  authorization  contains  only  the  categories 
1,6,7  when  he  logs  in  from  terminal  t3  on  project  p3.  If  any  one  of 
the  four  tables  is  left  out  in  the  calculation  of  this  maximum,  the 
process  authorization  will  contain  extra  categories.  As  in  the  pre- 
vious tests,  the  user  must  login  and  chose  a "greater",  "equal"  and 
"lower"  category  set  to  determine  which  categories  are  actually  set. 
Unfortunately,  if  more  than  one  of  the  categories  chosen  by  the  user 
on  the  login  line  is  not  within  the  calculated  minimum  authoriza- 
tion, the  login  will  be  rejected  and  there  will  be  no  way  to  deter- 
mine which  of  tne  categories  were  illegal.  Therefore,  several 
logins  must  be  tried. 

The  table  below  summarizes  the  11  logins  that  are  to  be  attempted. 
PAA-19  to  PAA-22  are  rejected  because  one  of  the  categories  speci- 
fied is  not  included  in  one  of  the  four  tables.  The  first  four 
tests  thus  check  that  each  of  the  tables  are  included  in  the  catego- 
ry verification.  PAA-23  determines  that  three  of  the  categories 
that  appear  in  all  the  tables  are  indeed  included.  PAA-24  deter- 
mines that  a user  can  select  a category  set  that  is  a subset  of  the 
maximum  authorized.  PAA-25  checks  the  default  case  of  unclassified, 
no  categories.  PAA-26  checks  the  user  settable  default.  For  this 
test,  the  user  logs  in  and  picks  a default  authorization  of  C,6,7» 

On  the  next  login,  this  default  should  be  used.  PAA-27  and  PAA-28 


^See  definitions  on  page  13. 

10The  answering  service,  which  reads  the  user's  login  line,  does  not 
notify  the  user  of  his  maximum  allowable  authorization.  Even  if  it 
did,  however,  such  a message  could  not  be  trusted  to  be  correct. 
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test  the  PDT  defaults  for  p4,  and  PAA-29  checks  that  the  operator  is 
notified  when  a category  in  the  CDT  is  not  in  the  PNT. 


user  project  login  cat.  result 
terminal 


PAA-19: 

U^4 

P3 

t3 

1,2, 6, 7 

rejected 

PAA-20 : 

u4 

P3 

t3 

1,3, 6, 7 

rejected 

PAA-21  : 

u4 

p2 

t2 

1,4, 6, 7 

rejected 

PAA-22 : 

u4 

P3 

t3 

1,5, 6, 7 

rejected 

PAA-23 : 

u4 

P3 

t3 

1,6,7 

accepted 

PAA-24 : 

u4 

P3 

t3 

1,6 

accepted 

PAA-25: 

u4 

P3 

t3 

none 

process  authorization  U,  no  category 

PAA-26: 

u5 

P3 

t3 

default 

process  authorization  C,6,7 

PAA-27: 

u4 

p4 

t3 

4, 5, 6, 7 

rejected 

PAA-28: 

u4 

p4 

t3 

4,5,6 

accepted 

PAA-29: 

u4 

P3 

t4 

none 

rejected,  notify  operator 

PAA-30  to  PAA-33:  Category  tests  at  new_proc. 


The  final  series  of  tests  checks  the  new_proc  options  identically  to 
that  in  PAA-15  to  PAA-18.  As  in  PAA-15  to  PAA-18,  it  is  assumed 
that  the  PNT,  PDT  and  CDT  values  of  the  maximum  category  set  cannot 
be  exceeded.  The  table  below  summarizes  the  tests  made. 


US 

er-pro j-term 

auth. 

action 

new 

authoriza 

PAA-30: 

u4  p3  t3 

1,6,7 

abnormal 

term. 

1,6,7 

PAA-31 : 

u4  p3  t3 

1,6,7 

new__proc 

to 

1,6 

1,6 

PAA-32: 

u4  p3  t3 

1,6 

new_proc 

to 

1,7 

1,7 

PAA-33: 

a4  p3  t3 

1,7 

new_proc 

to 

1,4 

rejected 

PAA-34:  Default  too  large. 

The  default  authorization  as  set  by  the  user  in  PAA-26  should  still 
be  in  force.  Since  the  default  should  apply  to  the  user  no  matter 
which  project  or  terminal  he  uses,  it  is  possible  that  this  default 
may  be  greater  than  that  allowed  for  some  project.  For  this  test, 
user  u5,  who  currently  has  a default  of  C,6,7,  tries  to  login  under 
project  p4,  which  has  an  isolated  category  set.  This  login  should 
be  rejected. 


ACCESS  TO  SEGMENTS 

Although  there  are  other  types  of  objects  within  Multics  to  which 
access  is  controlled,  segments  can  be  considered  most  basic  because 
access  to  them  is  monitored  directly  by  hardware.  Because  these  di- 


rect  segment  access  controls  are  so  fundamental  (many  other  types  of 
access  control  depend  on  them),  it  was  judged  necessary  to  test  the 
existing  Multics  "need  to  know"  controls  for  segments  as  well  as  the 
new  security  controls.  The  tests  of  the  two  types  of  controls  are  en- 
tirely distinct  and  will  therefore  be  discussed  separately  within  this 
subsection  under  the  headings  "ACL  Controls"  and  "Security  Controls". 

Design  Description  - ACL  Controls 

As  briefly  mentioned  earlier,  each  segment  in  the  system  has  an 
Access  Control  List  (ACL)  that  specifies  the  types  of  access  any  user 
of  the  system  has  to  that  segment.  When  a segment  is  first  referenced 
by  a process,  the  ACL  of  the  segment  is  searched,  and  if  at  least  one 
of  the  three  access  control  bits  (read,  execute  or  write)  is  on  for 
the  current  user,  the  segment  may  be  "initiated".  During  initiation  a 
segment  descriptor  word  (SDW)  is  created  containing  a pointer  to  the 
segment  and  the  three  access  control  bits  from  the  ACL  that  apply  to 
the  current  user.  This  SDW  is  referenced  by  the  hardware  on  every  ma- 
chine instruction  that  accesses  the  segment.  If  an  instruction  is  ex- 
ecuted that  attempts  a type  of  access  to  that  segment  not  allowed  by 
the  access  control  bits  in  the  SDW,  a fault  occurs  and  the  operation 
is  inhibited. 

The  proper  functioning  of  hardware  with  respect  to  the  SDW  access 
control  bits  is  tested  by  a hardware  "subverter,"  discussed  in  another 
document  [9],  Though  some  of  the  hardware  tests  are  effectively  dup- 
licated by  the  procedures  discussed  here,  the  purpose  of  the  ACL  con- 
trol tests  is  to  verify  that  the  supporting  software  in  hardcore  that 
maintains  ACLs  (setting,  listing,  searching,  etc.)  works  properly. 
Also,  since  a great  deal  of  interpretive  ACL  searching  and  validation 
is  performed  by  software  before  the  SDW  is  created  during  initiation, 
the  proper  functioning  of  this  software  must  be  verified.  The  follow- 
ing paragraphs  discuss  the  Multics  ACL  mechanism  as  it  appears  to  the 
average  user.  This  information  is  extracted  from  the  Multics 
Programmers'  Manual  [10],  and  gives  an  idea  of  the  types  of  operations 
software  must  perform  in  the  maintenance  of  ACLs.  Hardcore  is  com- 
pletely responsible  for  the  maintenance  of  ACLs  as  described  here. 

The  only  role  played  by  user  level  software  is  in  providing  a command 
level  interface  to  hardcore. 

The  ACL  on  a segment  created  by  the  user  is  a linear  list  of  "en- 
tries". Each  entry  is  composed  of  a "group  identifier"  and  access 
mode  indicators.  The  group  identifier  delineates  a set  of  Multics 
processes  and  is  made  up  of  three  components  as  represented  below: 

user. project. tag 
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The  user  and  project  are  character  strings,  and  the  tag  is  a single 
character  indicating  a process  type.  Any  of  these  three  components 
can  also  be  the  single  character  The  access  mode  that  corres- 

ponds to  a group  identifier  may  be  any  combination  of  read,  execute 
and  write  (r,  e,  w)  or  null  (n).  As  an  example,  the  ACL  of  a segment 
may  appear  as  follows: 


Drone_1 . blithe. a 

rew 

Drone_2. Kith. * 

re 

* . Kith. * 

rew 

* .SysDaemon. * 

n 

*.«.« 

r 

The  ordering  of  entries  with  respect  to  the  components  is  impor- 
tant, w'hen  an  ACL  is  sorted,  components  consisting  of  are  consid- 
ered to  follow  corresponding  components  not  consisting  of  where 

the  s.  rting  is  by  the  three  components,  left  to  right. 

Every  process  in  Multics  has  a permanently  assigned,  non-forge- 
able  access  identifier.  This  access  identifier  is  composed  of  the  us- 
er's name,  project,  and  process  type  as  is  a group  identifier,  except 
that  is  not  used.  For  example,  the  user  Drone_2,  logging  in  from 
a terminal  under  the  project  Kith,  is  given  a process  with  the  access 
identifier  Drone_2.Kith.a,  where  the  tag  "a"  signifies  an  interactive 
process. 

If  the  user  Drone_2  now  wants  to  access  a segment  having  the  ACL 
shown  above,  a search  of  the  ACL  is  made  for  a match  with  the  process 
identifier.  In  this  search,  components  of  the  group  identifiers  in 
the  ACL  consisting  of  are  considered  to  match  any  corresponding 
component  of  tne  process  identifier.  The  access  mode  of  the  first  ACL 
entry  that  matches  is  the  process'  access  to  the  segment.  In  the  ex- 
ample, the  first  match  was  wit/i  tne  second  entry  "Drone_2.Kith. *" , so 
the  access  is  "re",  note  that  the  third  entry  would  have  applied  to 
this  process  if  tne  second  entry  was  not  there.  In  this  particular 
example  all  users  under  the  project  "Kith"  have  "rew"  access  except 
the  user  "0rone_2",  who  has  only  "re"  access.  If  the  mode  for  a pro- 
cess is  "null",  or  if  there  is  no  match  in  the  ACL,  no  access  to  the 
segment  is  permitted  and  the  segment  may  not  be  initiated.  Otherwise, 
an  3DW  is  created  and  the  mode  bits  from  the  ACL  are  copied  into  it. 
From  this  point  on  the  hardware  takes  over  in  controlling  access  to 
the  segment  on  each  instruction. 

Test  Procedures  - ACL  Controls 

In  order  to  manipulate  ACLs  of  segments,  the  user  need  only  have 
modify  permission  on  the  containing  directory.  The  actual  contents  of 
the  ACL  entries  are  left  entirely  up  to  the  discretion  of  the  user. 
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The  user  normally  manipulates  ACLs  by  calling  commands  that  provide 
interlaces  to  the  hardcore  primitives  that  perform  the  function  de- 
sired. Though  it  is  important  that  the  user  level  commands  work  prop- 
erly, only  tests  of  the  actual  hardcore  primitives  are  made.  If  a 
user  does  not  trust  the  system  provided  ACL  commands,  he  can  always 
bypass  them  and  call  these  primitives  himself. 

There  are  five  primitive  functions  to  create,  add  to,  delete 
from,  list,  and  replace  segment  ACLs: 

create 
add 

delete 
list 

delete/create 

A series  of  automated  tests  can  check  that  all  five  functions  perform 
as  expected.  These  tests  are  broken  up  into  five  groups.  The  first 
four  groups  check  the  mutual  consistency  of  hcs_$list_acl  with  the 
other  four  primitives,  and  the  last  group  checks  that  the  ACL  as  pre- 
pared is  properly  copied  into  the  SDW  and  enforced.  There  are  also 
checks  to  ensure  that  the  ACL  cannot  be  made  to  contain  "garbage"  that 
might  confuse  the  system  into  misinterpreting  the  ACL.  For  these 
tests  the  user  ul  logs  in  under  project  pi  from  terminal  tl.  Since 
security  controls  are  being  ignored  for  these  tests,  the  entire  test 
sequence  can  be  assumed  to  take  place  at  system_low  or  some  other  sin- 
gle authorization  level.  Note  that  if  any  error  is  detected  in  these 
tests,  then  the  entire  test  of  the  ACL  controls  is  terminated  with  an 
appropriate  error  message.  This  is  because  the  impact  of  a detected 
error  in  the  ACL  controls  is  difficult  to  determine.  In  the  para- 
graphs below,  a brief  description  of  the  hcs_  entry  point  being  tested 
precedes  the  discussion  of  each  group. 

SAC-1:  Consistency  of  hcs_$append_branch  with  hcs_$list_acl. 

The  primitive  hcs_$append_branch  is  used  to  create  a segment  and  to 
initialize  the  ACL  of  the  segment  to  a certain  "initial  ACL"  plus 
the  group  identifier  for  the  current  user  and  project  with  a specif- 
ic access  mode.  The  initial  ACL  is  a special  ACL  obtained  from  a 
list  stored  in  tne  containing  directory.  The  initial  ACL  itself  is 
maintained  with  a set  of  primitives  similar  to  the  segment  ACL  prim- 
itives, but  they  are  not  tested  in  this  series.  The  default  initial 
ACL  for  segments  is  empty.  However,  hcs_$append_branch  also  auto- 
matically gives  "rw"  access  to  all  SysDaemons.  Thus,  assuming  the 
user  ul  creates  a segment  using  hcs_$append_branch , specifying  his 
access  mode  as  r,  the  resulting  ACL  should  appear  as  follows: 


hcs_$append_branch 
hcs_$add_acl_en tries 
hcs_$delete_acl_en tries 
hcs_$list_acl 
hcs_$replace_acl 
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a Up  1 . * r 

•.SysDaemon. * rw 

For  this  test  a segment  is  created  with  the  above  ACL  and  then 
hcs_$list_acl  is  called  to  check  this  ACL. 

SAC-2  to  SAC-7:  Consistency  of  hcs_$add_acl_entries  and  hcs_$list_acl 

The  primitive  hcs_$add_acl_entries  adds  or  changes  entries  in  an  al 
ready  existing  ACL.  For  this  group,  a segment  is  created  as  in 
SAC-1  with  the  following  ACL: 

u 1 . p 1 . * rw 

•.SysDaemon.*  rw 

Six  attempts  then  are  made  to  add  entries  to  this  ACL.  These  at- 
tempts check  that  hcs_$add_acl_entries  does  nothing  when  supplied 
badly  formed  ACL  entries,  but  correctly  changes  or  inserts  when 
supplied  well  formed  ACL  entries.  After  each  attempt,  a check  is 
made  to  verify  that  hcs_$list__acl  yields  the  ACL  expected.  Part  of 
the  test  is  to  verify  that  the  additional  ACL  entries  are  inserted 
into  the  proper  place  in  the  ACL,  since  the  order  is  very  important 
The  following  table  summarizes  these  six  tests: 


Additions 

Result 

Resultant  ACL 

3AC-2 : 

ul .p2.* 

r 

No  entries 

u 1 . p 1 . * 

rw 

ci » b % c » d 

re  w 

added 

•.SysDaemon.* 

rw 

SAC-3: 

ul .p2.* 

r 

Entry  added 

u 1 .p  1 . * 

rw 

ul ,p2.* 

r 

* .SysDaemon. * 

rw 

SAC- 4: 

ul  .p2.# 

re 

Entry 

ul .pi .* 

rw 

changed 

ul  .p2.* 

re 

•.SysDaemon.* 

rw 

SAC-5: 

u2.p2.« 

re 

Entry  added 

u 1 . p 1 . * 

rw 

ul  .p2. * 

re 

u2.p2.* 

re 

* .SysDaemon. * 

rw 

SAC- 6: 

u2.p2.b 

re  w 

Entry  added 

u2.p2.b 

rew 

ul . pi . * 

rw 

ul  .p2.* 

re 

u2. p2. * 

re 

•.SysDaemon. * 

rw 
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Additions 


Result 


Resultant  ACL 


SAC-7: 

».p1.* 

r 

Entries 

u2.p2.b 

rew 

u2.*.» 

r 

added  and 

ul.pl.* 

rew 

ul  .pi  .* 

rew 

changed 

ul .p2.* 

re 

».».* 

e 

u2.p2.« 

re 

u2. *. * 

r 

*.SysDaemon. 

* rw 

».p1.* 

r 

*.*.* 

e 

SAC-2 

should  add  no 

entries  because  there 

is  an  error  in 

one  of 

entries  to  be  added 

( four 

components  a.b. 

c.d  instead  of 

three) . 

SaC-3 

checks  that  one  new 

entry  that  has 

the  same  user  and  tag, 

a different  project,  as  another  entry  is  added  in  the  proper  place. 
SAC-4  checks  that  "adding"  an  entry  for  a group  identifier  already 
on  the  ACL  results  in  replacement  of  that  entry  with  the  new  access 
mode.  SAC-5  adds  a new  entry  which  is  the  same  as  another  but  dif- 
fers in  user  name.  SAC-6  adds  a new  entry  that  differs  only  in  the 
tag  from  some  other  entry.  SAC-7  adds  a list  of  four  entries,  pur- 
posely out  of  order,  to  check  that  each  is  properly  inserted  into 
the  ACL. 

SAC-d  and  SAC-9:  Consistency  of  hcs_$delete_acl_entries  and 
hcs_$list_acl. 

The  function  hcs_$delete_acl_entries  deletes  specific  entries  from 
an  ACL.  A segment  is  first  created  with  the  following  ACL: 

ul.pl.a  rew 

u2.p2.a  rew 

u2.p3*a  re 

ul  .pi . * rw 

*.SysDaemon. * rw 

*. p2. * r 


Two  attempts  are  then  made  to  delete  entries  from  this  ACL.  These 
attempts  check  that  hcs_$delete_acl_entries  does  nothing  when 
supplied  badly  formed  ACL  entries,  but  correctly  ignores  or  deletes 
when  supplied  well  formed  ACL  entries.  After  each  attempt,  a check 
is  made  to  verify  that  hcs_$list_acl  yields  the  ACL  expected.  The 
following  table  summarizes  this  group.  Note  that  in  SAC-8,  the  il- 
legal entry  has  fewer  than  three  components,  instead  of  more  than 
three  as  in  SAC-2. 
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Deletions 


Result 


Resultant  ACL 


SAC-8:  u 1 . p 1 . * 

No  entries 

ul  .pi  .a 

rew 

u2.p2.a 

deleted 

u2.p2.a 

re  w 

u3.p4.* 

u2.p3-a 

re 

•.SysDaemon. * 

ul  .pi . * 

rw 

a.  b 

*. SysDaemon 

„*  rw 

* . p2. * 

r 

SAC-9:  ul.pl.* 

Legitimate 

ul  .pi  .a 

rew 

u2.p2.a 

entries 

u2.p3*a 

re 

u3.p4.* 

deleted 

* . p2. * 

r 

•.SysDaemon. * 

SAC- 10  to  SAC- 12:  Consistency 

of  hcs_$replace 

_acl  and  hcs 

_$list_aclw 

The  primitive  hcs_$repiace_ 

acl  replaces  an 

entire  ACL. 

It  is  equiv 

alent  to  using  hcs_$delete_ 

acl_entries  for 

every  entry 

and  then  cal 

ling  hcs_$add_acl_entries  with  a user-supplied  list.  A segment  is 
created  with  the  following  ACL: 

ul .pi  . * rw 

•.SysDaemon.*  rw 

Three  attempts  are  made  to  replace  this  ACL  with  another  ACL.  These 
attempts  check  that  hcs_$replace_acl  does  nothing  when  supplied  a 
replacement  ACL  with  badly  formed  ACL  entries,  but  correctly  con- 
structs a new  ACL  when  supplied  a replacement  ACL  with  all  well 
formed  entries.  After  each  attempt,  a check  is  made  to  verify  that 
hcs_$list_acl  yields  the  ACL  expected.  The  following  table  summar- 
izes this  group. 


Replacement 

Result 

Resultant  ACL 

SAC- 10: 

ul  .pi  .a 

rew 

ACL  replaced 

ul  .pi  .a 

rew 

*.*.* 

r 

u2. p2. * 

rw 

•.SysDaemon. * 

rw 

*.  SysDaemon.  • 

rw 

u2.p2.» 

rw 

*.*.* 

r 

SAC-1  1 : 

u3.*.* 

r 

No  replace 

Unchanged 

a.b.c.d 

rew 

SAC-12: 

(empty  ACL) 

ACL  replaced 

(empty  ACL) 

SAC- 13  to 

SAC-25:  Control 

. of 

access. 

tions  is  assured.  The  final  group,  consisting  of  SAC-13  through 
SAC-25,  checks  that  an  ACL  of  a segment  as  set  by  the  four  primi- 
tives does  control  correctly  the  access  of  a process  to  that  seg- 
ment. To  do  this,  a different  user  u2  under  a project  p2,  logs  in 
at  a second  terminal  t2.  Let  PI  and  P2  indicate  the  processes  for 
ul  and  u2  respectively.  User  ul  first  creates  a segment  with  a spe- 
cific ACL  as  shown  in  the  table  below  under  SAC-13-  Using  the  prim- 
itives hcs_$add_acl_entries,  hcs_$delete_acl_entries , and 
hcs_$replace_acl , a series  of  changes  are  made  to  this  ACL.  After 
each  change,  a check  is  made  to  verify  that  the  access  that  process 
P2  is  given  to  the  segment  is  consistent  with  the  current  ACL.  The 
check  consists  of  using  the  try_reference_  subroutine  described  on 
page  24  to  access  the  segment.  This  particular  ACL  and  series  of 
changes  were  chosen  also  to  ensure  that,  when  the  ACL  of  a segment 
is  examined  in  order  to  determine Jthe  access  allowed  a particular 
process,  the  process  is  associated  with  the  correct  ACL  entry. 

These  thirteen  tests  are  summarized  in  the  table  below.  Under  the 
heading  "Entry"  the  hcs_  entries  used  to  change  the  ACL  are  named. 
Under  ACL,  either  the  entire  new  ACL  is  shown  (when  "result:"  is  in- 
dicated), or  the  specific  entries  added  or  deleted  are  named. 


Entry 

ACL 

Access  of  P2 

SAC-13: 

(append 

4 add) 

result : 

u2.p2.x 

re  w 

null 

u2.p3-a 

rew 

u3.p2.a 

rew 

u2.p2.a 

null 

u 1 . p 1 . * 

rew 

u2.p2. * 

rew 

u2.*.a 

rew 

u2.*.* 

rew 

*.p2.a 

rew 

•.SysDaemon.* 

rw 

* .p2. * 

rew 

*.*.a 

rew 

».*.* 

rew 

SAC-14: 

add : 

u2.p2.a 

r 

r 

SAC- 15: 

add : 

u2.p2.a 

r 

re 

SAC-16: 

add : 

u2. p2.a 

rw 

rw 

SAC-17: 

add : 

u2.p2.a 

rew 

rew 

Entry 


ACL 


Access  of  P2 


SAC-ld: 

(delete 

& add ) 

result : 

u2.p2.x 

rew 

r 

u2.p3*a 

rew 

u3.p2.a 

rew 

u 1 .pi . * 

rew 

u2.p2. * 

r 

u2. *.a 

rew 

u2.*.* 

rew 

*.p2.a 

rew 

*.SysDaemon,* 

rw 

*.p2.» 

rew 

*.*.a 

rew 

* fc  # # 

rew 

SAC-19: 

delete: 

u2,p2.» 

r 

r 

add : 

u2. *.a 

r 

SAC-20: 

delete : 

u2, * .a 

r 

r 

add : 

u2. * . * 

r 

SAC-21 : 

delete : 

u2. * . * 

r 

r 

add : 

*.p2.a 

r 

SAC-22: 

delete : 

*.p2.a 

r 

r 

add : 

*.p2.* 

r 

SAC-23: 

delete : 

*.p2.* 

r 

r 

add : 

*.*.a 

r 

SAC-24: 

(delete 

& add) 

result : 

u2.p2.x 

rew 

r 

u2.p3*a 

rew 

u3.p2.a 

rew 

ul.pl.* 

rew 

•.SysDaemon.* 

rw 

*.*.* 

r 

SAC-25: 

replace 

u2.p2.x 

rew 

null 

u2.p3*  a 

rew 

u3*p2.a 

rew 

ul.pl.a 

rew 

In  oAC-13,  process  P2  should  be  associated  with  the  fourth  entry  in 
the  list,  and  therefore  should  be  given  null  access.  The  first 
three  entries  each  match  P2's  access  identifier  of  u2.p2.a  in  exact- 
ly one  of  the  three  components,  and  the  fifth  does  not  matcn  p 2 in 


any  component.  The  other  entries  all  match  P2  in  all  three  compo- 
nents, utilizing  different  positions  of  the  identifier  (except 
the  one  for  *.SysDaemon. * ) , but  they  should  be  ignored  because  they 
follow  the  first  match  with  u2.p2.a.  SAC-14  through  SAC-17  check 
that  the  different  combinations  of  modes  are  enforced  properly. 

Only  the  four  generally  useful  combinations  are  checked,  ratner  than 
all  possible  combinations.  In  SAC-18  through  SAC-24,  the  first 
matching  entry  from  each  previous  test  is  deleted  from  the  ACL,  and 
the  next  entry's  mode  is  changed  to  "r"»  These  verify  that  compo- 
nents of  "*"  are  properly  matched.  Finally  SAC-25  checks  that  there 
is  null  access  when  there  is  no  match. 

Design  Description  - Security  Controls 

rf/itn  the  application  of  security  controls  to  segment  references, 
the  access  mode  as  determined  by  the  ACL  on  the  segment  may  be  further 
restricted.  The  security  controls  can  be  thought  of  as  being  applied 
to  the  three  mode  bits  (r,  e,  w)  just  before  they  are  put  into  the 
SDW.  As  expressed  in  the  representation  of  PL/I  code  at  the  middle  of 
page  22,  these  controls  state  that 

1)  if  the  authorization  of  the  process  is  "equal  to"  the  access 
class  of  the  segment,  leave  the  mode  unchanged; 

2)  if  the  authorization  is  "greater  than"  the  access  class  of  the 
segment,  subtract  "w"  access; 

3)  in  all  other  cases,  tne  access  to  the  segment  is  null,  and  the 
segment  is  not  initiated. 


Tnere  are  further  complications  with  regard  to  segment  access  in- 
volving the  ring  structure  as  discussed  in  Section  I.  The  ring  struc- 
ture imposes  additional  controls  on  access  to  segments,  and  is  en- 
forced by  hardware  utilizing  additional  fields  in  the  SDtf.  Most  of 
the  hardware  supported  ring  structure  is  tested  by  the  hardware  sub- 
verter  discussed  earlier.  There  are  also  commands  in  support  of  the 
ring  structure  as  for  ACLs  (for  example,  each  segment  has  a set  of 
ring  brackets  that  can  be  set  by  using  certain  commands)  but  the  deci- 
sion was  made  not  to  test  these  because  the  only  way  a user  can  set 
the  ring  brackets  of  a segment  below  his  own  validation  level  is  to 
have  access  to  a special  "gate"  segment  that  is  protected  by  the  ACL 
controls  already  tested.  Also,  bugs  in  these  commands  are  unlikely 
since  the  interface  is  quite  simple.  It  is  possible  for  the  user  to 
create  his  own  subsystems  using  rings  as  a protection  mechanism,  but 
since  there  is  no  interaction  between  the  ring  structure  and  the  secu- 
rity and  ACL  controls,  bugs  in  the  user's  subsystem  can  only  involve 
data  to  which  he  already  has  access.  Such  a subsystem  would  have  to 
be  thoroughly  tested  before  it  could  be  relied  upon  to  protect  data 
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via  the  ring  mechanism 


Test  Procedures  - Security  Controls 

Many  of  the  segment  access  checks  have  already  been  performed  by 
the  authorization  tester  during  tne  process  authorization  assignment 
tests.  The  segment  test  procedures,  however,  do  not  assume  the  au- 
thorization tester  has  been  run,  and  thus  are  entirely  independent  of 
any  other  group  of  tests.  These  tests  can  all  be  automated  with  no 
manual  intervention  required. 

The  3EG_TEST  directory  set  up  during  test  environment  initializa- 
tion described  on  page  31  (Figure  3)  is  referenced  in  these  tests. 

All  tests  are  performed  at  a single  login  session,  ^authorization 
secret ,c 1 ,c2.  Immediately  after  login,  the  test  program  is  called  to 
perform  all  the  tests  as  outlined  in  the  table  below.  In  this  table, 

S indicates  the  access  class  of  the  segment  and  P is  the  authorization 
of  the  process  (secret, cl ,c2) . 


Test 

Attempted  access 

Segment 

Result 

SSC-1 

3=P 

write 

SI 

access 

allowed 

SSC-2 

S=P 

read 

SI 

access 

allowed 

SSC-3 

3=  P 

execute 

SI 

access 

allowed 

SSC-'t 

S<P 

read 

S2 

access 

allowed 

3SC-5 

S<P 

execute 

S2 

access 

allowed 

3SC-6 

3<P 

write 

S2 

access 

denied 

S8C-7 

S>P 

initiate 

S3 

access 

denied 

SSC-3 

S6P 

read 

SM 

access 

allowed 

3SC-9 

SCP 

execute 

S4 

access 

allowed 

SSC-1 0:  3CP 

write 

S4 

access 

denied 

SSC-1 1:  P6S 

initiate 

35 

access 

denied 

SSC-12:  3*P 

initiate 

S6 

access 

denied 

In  the  above  table,  the  symbols  "<"  and  ">"  refer  to  the  comparison  of 
level  numbers,  category  sets  being  equal.  The  symbols  "6"  and 
mean  "subset"  and  "isolated"  in  reference  to  category  sets,  with  level 
numbers  equal. 


The  tests  listed  are  self  explanatory.  References  to  the  seg- 
ments are  made  using  the  subroutine  try_reference_.  Tests  SSC-1 
through  3SC-7  check  the  relationships  between  level  numbers,  and  SSC-8 
through  SSC-1 2 check  the  relationships  between  category  sets. 
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ACCESo  TO  DIRECTORIES 


For  directories  Multics  includes  ACL  controls,  ring  controls  and 
security  controls  that  operate  in  a manner  similar  to  that  for  seg- 
ments. However,  all  of  these  controls  are  enforced  by  software  rather 
than  by  hardware.  In  order  to  reasonably  limit  the  scope  of  testing, 
only  the  security  controls  are  tested. 

Design  Description 

Tnough  similar  to  the  segment  controls,  the  directory  access  con- 
trols are  in  reality  much  more  complex.  This  complexity  stems  from 
the  fact  that  directories  are  never  directly  referenced  by  the  user, 
but  are  referenced  through  hardcore  in  an  interpretive  manner.  In- 
stead of  setting  bits  in  an  SD'w  the  first  time  the  segment  is  refer- 
enced at  initiation  time,  the  hardcore  supervisor  must  verify  that  the 
user  has  access  on  every  call  to  every  hardcore  primitive  that  access- 
es directories.  An  additional  complication  is  that,  while  the  access 
class  of  a segment  must  be  the  same  as  that  of  its  parent  directory 
(and  therefore  information  about  the  segment  (name,  length,  etc.) 
stored  in  the  directory  is  of  the  same  access  class  as  the  segment 
contents),  the  access  class  of  a directory  may  be  greater  than  that  of 
its  parent. 

Every  time  a segment  is  initiated  its  parent  directory  must  be 
accessed.  Without  security  controls,  it  is  not  necessary  for  a user 
to  have  any  access  to  the  parent  directory  (as  specified  in  the  ACL  of 
that  directory)  in  order  to  access  the  segment,  as  long  as  he  has  some 
access  to  the  segment.  Even  though  there  is  no  access  to  the  directo- 
ry, however,  there  is  implicit  access  to  various  items  in  the  branch 
for  the  segment.  (The  term  "branch"  is  used  to  refer  to  the  attri- 
butes of  the  segment  or  directory  stored  in  the  parent  directory.) 

The  bit  count  of  a segment,  for  example,  may  be  obtained  from  the  par- 
ent directory  with  any  access  to  the  segment.  There  is  also  an  impli- 
cit "write"  access  to  items  such  as  the  date  time  used  (dtu)  which  are 
modified  by  the  system  when  the  segment  is  accessed.  Thus,  it  is  pos- 
sible, even  with  no  access  to  a directory,  to  examine  and  even  modify 
items  stored  in  that  directory. 

The  ‘-property  requires  that  it  must  not  be  possible  for  a pro- 
cess of  a higher  authorization  to  write  data  that  can  be  read  by  a 
process  of  a lower  authorization.  In  a typical  case  where  a secret 
process  accesses  an  unclassified  segment  (contained  in  an  unclassified 
directory)  the  secret  process  normally  should  have  no  "write"  access 
to  the  segment  or  the  directory.  Clearly,  it  would  be  a violation  if 
attributes  such  as  the  dtu  of  the  segment  were  modified  and  then  read- 
able by  unclassified  processes.  With  the  incorporation  of  security 
controls  it  has  become  necessary  to  restrict  implicit  modification  of 


53 


A 


i 


items  in  a directory  having  an  access  class  below  the  authorization  of 
the  process. 

Test  Procedures 

The  three  directory  access  modes  "status"  (s),  "modify"  (m)  and 
"append"  (a)  are,  for  the  purposes  of  security,  considered  equivalent 
to  the  segment  access  modes  as  follows: 

s = r , e 
m,  a = w. 

The  first  group  of  directory  access  tests  is  exactly  the  same  as  the 
test  of  tne  segment  security  controls,  except  that  there  is  no  expli- 
cit test  of  initiate  for  a directory,  and  "a"  access  is  not  tested 
separately.  The  subroutine  try_dir_reference_  is  used  to  make  the  di- 
rectory accesses.  This  subroutine,  when  given  the  name  of  a directory 
to  access,  tries  to  use  every  hcs_  (hardcore)  primitive  (documented  in 
the  MPM  [10])  to  access  that  directory.  In  each  case,  both  "s"  and 
"m"  access  modes  are  checked.  This  first  group  of  tests  is  outlined 
in  the  table  below.  Refer  to  Figure  4 on  page  32  for  an  illustration 
of  the  directories  referenced  in  these  tests. 

Test  Directory  Mode  allowed 


DSC- 1 : 

D=P 

D1 

sm 

DSC-2 : 

D<P 

D2 

s 

DSC-3 : 

D>P 

D3 

null 

DSC-4 : 

D6P 

D4 

s 

DSC- 5: 

PSD 

D5 

null 

DSC-6: 

Vi? 

D6 

null 

In  this  table  the  symbol  D indicates  the  access  class  of  the  directory 
being  referenced.  The  meanings  of  the  other  symbols  are  the  same  as 
those  in  the  table  for  segments  on  page  52. 

The  above  tests  only  check  access  to  entries  that  already  exist 
within  directories  of  various  classifications.  Several  more  tests  are 
required  to  check  an  additional  primitive  hcs_$create_branch_  that  may 
be  used  to  create  directories  or  segments  of  any  access  class.  It 
must  be  verified  that  hcs_$create_branch_  cannot  be  used  to  create  il- 
legal hierarchy  configurations,  and  that  it  also  cannot  be  used  to 
pass  information.  Each  of  the  tests  DSC-7  to  DSC-17,  summarized  in 
the  table  below,  attempts  to  create  a directory  or  segment  of  a cer- 
tain access  class  within  another  directory.  For  these  tests,  it  is 
again  assumed  that  the  process  authorization  is  secret ,c 1 ,c2. 
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parent  directory  entry  created  reason  for 


name 

access  class 

name 

access  class 

quota 

failure 

DSC-7: 

D2 

C,c  1 ,c2 

dir 

S,c1  ,c2 

1 

no  "m"  to  D2 

D3C-8: 

D2 

C,c1  ,c2 

dir 

S,c1 

1 

no  "m"  to  D2 

DSC-9: 

D4 

C,c1 

dir 

C,c  1 

1 

no  "m"  to  D4 

DSC-10 

D3 

T,c1 ,c2 

dir 

S,c1  ,c2 

1 

no  "s"  or  "m" 

DSC- 1 1 

D5 

C,c1  ,c2,c3 

dir 

S,c  1 ,c2 

1 

no  "s"  or  "m" 

DSC- 12 

D 1 

S,c1  ,c2 

dir 

S,c  1 

1 

downgraded  dir 

DSC-13 

D 1 

S,c  1 ,c2 

dir 

system_low 

1 

downgraded  dir 

DSC-14 

D 1 

S,c1  ,c2 

dir 

S,c1  ,c2 

1 

(successful) 

DSC-15 

D1 

S,c  1 ,c2 

dir 

S,c1 ,c2,c3 

0 

zero  quota 

DSC- 16 

D 1 

S,c  1 ,c2 

seg 

S,c1  ,c2,c3 

- 

upgraded  seg 

DSC- 17 

[pd]  S,c 1 ,c2 

dir 

S,c1  ,c2,c3 

1 

(successful ) 

DSC-7  to  DSC-9:  Upgrade  in  lower  parent. 

These  three  tests  check  to  ensure  that  an  upgraded  directory  cannot 
be  created  in  a parent  directory  to  which  the  process  has  "s"  but  no 
"in"  permission  due  to  the  security  controls-  Both  DSC-7  and  DSC-9 
would  otherwise  be  legal.  DSC-6  should  be  illegal  anyway  because 
the  upgraded  directory  to  be  created  has  a lower  category  set. 

DSC-10  and  DSC- 11:  Upgrade  in  higher  parent. 

These  two  checks  further  verify  that  the  lack  of  "m"  permission  in- 
hibits creation  of  an  upgraded  directory.  This  time  the  parent  di- 
rectories are  of  a higher  level  and  category  set  than  the  process. 

D5C-12  and  DSC-13:  Downgraded  directory. 

These  two  tests  verify  that  it  is  not  possible  to  create  a downgrad- 
ed directory  in  which  the  access  class  of  the  directory  is  less  than 
that  of  the  parent.  With  respect  to  the  current  process  authoriza- 
tion, both  these  attempts  are  otherwise  legal.  The  purpose  of 
DSC- 13  is  to  check  that  system_low  is  not  treated  as  a special  case. 

DSC-14:  Directory  of  current  authorization. 

This  test  uses  hcs_$create_branch_  to  create  a directory  of  the  cur- 
rent authorization,  and  should  be  successful. 

DSC-15:  Upgraded  directory  with  zero  quota. 

When  calling  hcs_$create_branch_,  the  caller  specifies  a quota  for 
the  directory  to  be  created.  It  should  not  be  legal  to  create  an 
upgraded  directory  without  quota,  as  attempted  by  this  test. 
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DSC-16:  Upgraded  segment. 

The  hcs_$create_branch_  primitive  allows  the  caller  to  create  an  up- 
graded segment,  provided  his  validation  level  is  in  ring  1.  This 
option  is  for  use  by  the  message  segment  software,  which  runs  in 
ring  1.  The  user  whose  validation  level  is  4 should  not  be  able  to 
invoke  this  option. 

DSC-17:  Upgraded  directory  of  higher  access  class. 

Finally,  this  last  test  creates  a valid  upgraded  directory  of  a 
higher  access  class  than  the  current  process.  The  directory  is  cre- 
ated in  the  process  directory  because  otherwise  it  would  be  diffi- 
cult to  delete  from  the  hierarchy.  In  order  to  verify  that  this  di- 
rectory is  truly  upgraded,  try_dir_reference_  is  called  to  check  ac- 
cess to  it. 

DSC-18  to  DSC-20:  Implicitly  modified  attributes. 

There  are  three  final  tests  that  check  that  the  dtu  and  dtm  of  di- 
rectories and  segments  are  not  implicitly  modified  when  there  is  no 
modify  permission  (due  to  security  controls)  to  the  parent.  In  each 
of  these  tests,  the  access  class  of  the  parent  of  the  directory  or 
segment  being  referenced  is  less  than  the  authorization  of  the  pro- 
cess that  might  have  caused  the  dtu  or  dtm  to  be  modified.  The  ta- 
ble below  lists  the  name  of  the  directory  or  segment  and  its  parent, 
whose  dtu  and  dtm  are  checked. 


parent 

name 

DSC-18: 

DIR_TEST 

D 1 

DSC-19: 

D2 

DIR 

DSC-20: 

D2 

SEG 

In  DSC-18,  the  dtu  and  dtm  of  D1,  stored  in  the  parent,  should  not 
be  modified  because  the  access  class  of  D1  is  greater  than  that  of 
DIR_T£3T  and  the  access  class  of  DIR_TE3T  is  less  than  the  process 
authorization.  In  DSC-19  the  access  class  of  the  parent  (D2)  of  DIR 
is  equal  to  the  access  class  of  DIR,  but  lower  than  the  process  au- 
thorization. This  test  checks  that  the  reason  for  not  modifying  the 
dtu  was  due  to  tne  authorization  of  the  current  process  being 
"greater  than"  the  access  class  of  the  parent  directory  — not  be- 
cause the  parent  directory  had  a lower  access  class  than  the  direc- 
tory. DSC-20  checks  that  the  dtu  and  dtm  restrictions  also  apply  to 
segments. 
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COMMUNICATION  BETWEEN  PKOCESSES 


Processes  can  communicate  with  each  other  by  various  means:  seg- 
ment or  directory  sharing,  the  interprocess  communication  facility 
(IPC),  and  message  segments.  Segment  and  directory  sharing  are  auto- 
matically secure  if  the  segment  and  directory  controls  work  properly. 
IPC  and  message  segments  are  special  facilities  that  must  be  specifi- 
cally tested.  The  design  description  and  test  procedures  for  each  fa- 
cility will  be  presented  separately. 

Interprocess  Communication  - Design  Description 

IPC  is  conceptually  very  simple:  a process  sends  a message  of 
fixed  length  to  another  process.  With  security  controls,  the  authori- 
zation of  the  sending  process  is  attached  to  the  IPC  message  and  be- 
comes the  access  class  of  the  message.  A process  can  only  receive  a 
message  if  the  authorization  of  the  process  is  "greater  than"  or 
"equal  to"  the  access  class  of  the  message. 

Interprocess  Communication  - Test  Procedures 

IPC  is  tested  in  a straightforward  manner  by  having  processes  of 
various  authorizations  send  messages  to  one  process  having  a fixed  au- 
thorization. Since  it  is  inconvenient  to  test  with  more  than  one  or 
two  processes  (terminals)  at  a time,  a scheme  using  two  process  is 
used.  There  is  a sending  process  that  starts  at  a given  authorization 
and  trien  changes  its  authorization  using  the  new_proc  command.  At 
each  unique  authorization,  it  sends  a message  to  a second  receiving 
process.  This  receiving  process  remains  at  a fixed  authorization. 

The  table  below  lists  the  six  tests  (IPC-1  to  IPC-6)  that  are  to 
pe  performed.  The  sending  process  is  initially  logged  in  at 
system_low,  and  the  receiving  process  remains  logged  in  at  S,c1,c2. 
These  six  tests,  each  consisting  of  sending  a single  message  of  a giv- 
en access  class,  are  very  similar  to  the  segment  and  directory  securi- 
ty controls  tests.  In  fact,  an  exact  correspondence  with  the  tests 
DSC- 1 to  DSC-6  (see  page  54)  can  be  made,  except  that  the  sequence  has 
been  changed  so  that  the  "legal"  situations  come  up  first. 


PI 

relation 

results 

IPC-1 : 

S,c  1 ,c2 

PI 

= 

P2 

Message 

received 

I PC-2 : 

C,c 1 ,c 2 

PI 

< 

P2 

Message 

recei ved 

I PC- 3: 

S,c  1 

PI 

£ 

P2 

Message 

received 

IPC-4 : 

S,c 1 ,c2,c3  P2 

6 

PI 

Message 

not  received 

IPC-5: 

T,c  1 ,c2 

PI 

> 

P2 

Message 

not  received 

IPC-6: 

3, cl  ,c3 

PI 

t 

P2 

Message 

not  received 
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In  the  aoove  table  PI  is  the  authorization  of  the  first  process,  and 
P2  is  the  authorization  of  the  second  process,  which  stays  fixed  at 
S,c1,c2.  Tne  meanings  of  the  other  symbols  are  defined  below  the  ta- 
ble on  page  52. 

Message  Segments  - Design  Description 

Message  segments  are  special  segments  maintained  by  ring  1 soft- 
ware. A distinctive  property  of  message  segments  is  that  they  are 
multi-level.  Message  segments  contain  individual  messages  that  may 
have  been  put  there  by  processes  of  various  authorizations.  Each  mes- 
sage has  an  access  class  associated  with  it,  and  access  to  the  indivi- 
dual messages  is  subject  to  exactly  the  same  security  controls  as  is 
access  to  segments.  There  is  also  a special  kind  of  need  to  know  ac- 
cess control  for  messages  involving  the  five  access  control  bits: 

a add  any  message 

d delete  any  message 

r read  any  message 

o delete  or  read  only  own  messages 

s obtain  number  of  messages 

The  special  ACL  of  message  segments  (called  an  extended  ACL)  is  a list 
like  that  for  regular  segments,  except  that  the  five  bits  above  are 
used  instead  of  r,  e and  w. 

When  a user  creates  a message  segment,  usually  for  the  purpose  of 
receiving  mail  from  other  users,  the  ACL  normally  is  set  as  follows: 

adros  User. Project. * 

ao  *.*.» 

This  ACL  specifies  that  the  creator  of  the  message  segment  has  full 
access  to  all  messages,  and  that  all  other  users  have  full  access  to 
their  own  messages. 

When  security  controls  are  in  force,  the  effective  access  mode  to 
any  particular  message  may  be  furtner  restricted.  The  restrictions 
ensure  that  it  is  not  possible  to  violate  the  *-property  or  the  secu- 
rity condition.  In  particular,  a message  may  not  be  deleted  unless 
its  access  class  is  equal  to  the  process  authorization  (and  either  "d" 
or  "o"  access  is  permitted  in  the  extended  ACL),  and  a message  may  not 
be  read  if  its  access  class  is  "greater  than"  or  "isolated  from"  the 
process  authorization.  This  latter  restriction  also  applies  to  learn- 
ing of  the  existence  of  a message  through  the  "s”  access  mode. 

Because  message  segments  are  finite  resources,  it  is  possible  for 
a message  segment  to  fill  up.  When  there  is  no  more  room  in  a message 
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segment,  the  sender  is  notified,  even  if  he  has  no  access  to  any  of 
the  ether  messages  in  the  segment.  This  makes  it  possible  for  a Tro- 
jan Horse  to  pass  one  bit  of  information  (the  "message  segment  over- 
flow" condition)  to  another  cooperating  process,  even  if  the  second 
process  is  of  a lower  authorization.  In  order  for  this  scheme  to  pass 
any  significant  amount  of  information,  the  second  process  must  repeat- 
edly cause  the  overflow  condition  to  occur.  There  is  no  way  to  pre- 
vent such  an  occurrence  in  the  current  implementation  without  severely 
restricting  the  utility  of  message  segments,  so  the  solution  was  to 
audit  such  events  in  the  hope  that  the  penetrator  would  soon  get 
caught.  Under  normal  circumstances,  this  condition  should  occur  in- 
frequently enough  to  be  easily  distinguishable  from  a penetration  at- 
tempt . 

Message  segments,  as  a whole,  have  an  access  class  that  is  the 
maximum  access  class  of  any  message  that  may  be  put  into  them.  This 
value  is  set  to  the  user's  maximum  authorization  when  the  message  seg- 
ment is  created.  Enforcement  of  the  message  segment  access  class  is 
not  a requirement  for  security,  since  access  to  the  individual  mes- 
sages is  controlled.  Its  only  purpose  is  to  prevent  message  segments 
from  containing  messages  that  the  user  will  never  be  able  to  read. 

Message  Segments  - Test  Procedures 

Ideally  message  segments  should  be  tested  by  invoking  the  ring  1 
primitives  that  manipulate  them.  Unfortunately  these  ring  1 inter- 
faces are  considered  internal  to  Multics  and  no  documentation  is  gen- 
erally available.  In  addition,  they  are  subject  to  change.  In  order 
to  provide  a reasonable  test  of  message  segments  that  will  remain  gen- 
erally useful  in  the  future,  the  Multics  mail  facility  is  used.  The 
mail  command,  along  with  several  special  mailbox  commands,  is  a com- 
mand level  interface  to  the  ring  1 primitives.  For  these  tests  it 
will  be  assumed  that  the  user  is  not  able  to  bypass  any  controls  by 
invoking  ring  1 directly. 

There  are  again  six  tests  of  message  segments  similar  to  the  six 
for  IPC  tests.  The  test  procedure  consists  of  creating  a message  seg- 
ment and  sending  messages  to  it  from  processes  at  various  authoriza- 
tions. When  all  messages  are  sent,  an  attempt  is  made  to  access  those 
messages  from  a process  at  a specific  authorization  in  relation 
to  the  access  classes  of  the  messages. 

The  mailbox  is  initialized  by  a process  that  legs  in  at 
system_low,  and  creates  a message  segment  using  the  mbx_create  com- 
mand. This  process  then  new_procs  itself  to  each  of  six  authoriza- 
tions and  sends  a message  to  this  mailbox  while  at  each  authorization. 
When  the  six  messages  have  been  sent,  the  process  new_procs  to  S,c1,c2 
and  attempts  to  read  its  messages.  The  mail  command  is  not  very  spe- 
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cific  with  regard  to  individual  messages  --  The  only  options  are  to 
read  all  messages  and  to  delete  all  messages-  Thus,  when  the  mail 
command  is  invoked,  three  of  the  messages  to  which  the  user  has  read 
permission  should  be  printed,  and  the  other  three  should  not  be-  When 
the  user  attempts  to  delete  the  messages,  only  the  one  at  access  class 
S,c1,c2  should  get  deleted-  The  mail  command  is  invoked  again  after 
deletion  to  check  that  only  that  one  message  got  deleted. 

The  table  below  lists  the  access  classes  of  tne  messages  put  into 
the  mailbox.  There  are  not  actually  six  different  "tests",  since  the 
mail  command  is  invoked  only  twice  --  once  to  read  and  delete  all  the 
messages,  and  a second  time  to  check  on  the  deletion-  For  consistency 
with  IPC,  however,  this  test  will  be  listed  as  six  tests-  The  symbol 
K is  the  access  class  of  the  message  and  P is  the  access  class  of  the 
process.  The  other  symbols  have  been  defined  earlier. 


M 

relation 

read? 

deleted? 

MBX-1 

S , c 1 , c2 

M = 

P 

yes 

yes 

MbX- 2 

C,c  1 ,c2 

h < 

P 

yes 

no 

MBX-3 

S,c1 

M 6 

P 

yes 

no 

MBX- 4 

S,c  1 ,c2,c3 

p e 

M 

no 

no 

MBX- 5 

T , c 1 ,c2 

M > 

P 

no 

no 

MBX- 6 

S,c1,c3 

M i 

P 

no 

no 

MBX-7:  Deletion  of  mailbox. 

In  addition  to  the  deletion  of  individual  messages,  the  user  normal- 
ly has  the  ability  to  delete  his  entire  mailbox.  This  deletion 
should  not  be  allowed,  however,  if  there  are  messages  of  an  access 
class  below  his  current  authorization.  Of  course,  in  order  for 
a mailbox  to  contain  messages  of  a lower  authorization,  that  mailbox 
must  be  in  a directory  of  a lower  authorization;  otherwise  no  pro- 
cess of  a lower  authorization  could  have  known  of  the  existence  of 
the  mailbox.  Thus,  the  deletion  of  the  mailbox  would  normally  be 
subject  to  the  usual  rules  for  the  deletion  of  segments  in  a direc- 
tory of  a lower  access  class.  However,  this  test  for  mailboxes 
should  be  made  because  the  deletion  of  a mailbox  is  handled  by  ring 
1,  which  could  bypass  the  security  controls  if  it  chooses.  For  this 
test,  while  the  process  is  still  at  S,c1,c2,  the  user  attempts  to 


Note  that  it  must  be  possible  for  the  user  to  delete  a mailbox 
containing  messages  of  only  higher  and  equal  access  classes.  If  dele- 
tion were  restricted  because  of  the  presence  of  higher  access  class 
messages,  the  user  could  infer  the  existence  of  those  messages  by  not- 
ing that  the  mail  command  tells  him  that  there  are  no  messages  while 
at  the  same  time  he  cannot  delete  the  mailbox. 


invoke  the  mbx_delete  command  to  delete  the  mailbox.  This  deletion 
attempt  should  fail.  Finally,  if  desired,  the  user  can  new_proc  to 
system_low  and  delete  the  mailbox. 

Note  that  there  is  no  test  of  the  enforcement  of  the  maximum  ac- 
cess class  of  tne  message  segment,  since  this  feature  is  not  a re- 
quirement for  security.  Note  also  that  these  tests  assume  that  the 
current  user  has  "adros"  access  to  the  mailbox,  which  is  the  default 
condition  when  mailboxes  are  created. 


ACCESS  TO  I/O 

Ihe  area  of  input  and  output  has  traditionally  been  the  most  dif- 
ficult to  control  in  a secure  manner.  In  Multics  'without  security 
controls  a process  must  "attach"  a peripheral  device,  such  as  a tape 
drive  or  tecminal,  before  that  device  can  be  accessed.  This  attach- 
ment can  be  viewed  as  similar  to  the  act  of  initiation  for  a segment: 
the  process'  access  privileges  are  determined  at  attachment  time  and 
access  is  allowed  or  denied.  Since  all  I/O,  like  directory  references, 
is  ultimately  performed  by  hardcore  (unlike  references  to  segments 
which  are  made  directly  by  machine  instructions),  the  attachment  gives 
the  user  the  right  to  access  a particular  device  via  the  appropriate 
hardcore  entries. 

Because  of  the  complexity  of  I/O,  it  was  determined  that  bugs  in 
hardcore  I/O  routines  might  exist  that  could  be  exploited  by  the  user 
to  bypass  the  security  controls.  Since  validation  of  the  hardcore  I/O 
routines  is  not  currently  feasible,  the  decision  was  made  to  restrict 
attachment  of  devices  (otner  than  terminals)  to  system  processes  only. 
Any  I/O  that  a user  process  wants  to  perform  must  be  accomplished  by 
submitting  a request  to  a system  process  in  some  type  of  queue.  Mes- 
sage segments,  as  described  on  page  58,  are  used  to  hold  these  queues 
and  the  user  process'  request  is  in  the  form  of  a message  to  the  ap- 
propriate message  segment. 

The  security  controls  require  that  the  normal  rules  applying  to 
segment  accesses  also  apply  to  system  precesses  with  respect  to  I/O 
device  accesses.  Therefore  a process  will  only  be  able  to  use  a de- 
vice for  writing  if  the  authorization  of  the  process  is  "less  than"  or 
"equal  to"  the  access  class  of  the  device.  Heading  from  a device  is 
restricted  to  a process  having  an  authorization  "equal  to"  the  access 
class  of  the  device.  The  user's  indirect  access  to  the  I/O  device 
through  the  system  process  is  also  subject  to  the  same  controls.  Fol- 
lowing are  the  design  descriptions  and  test  procedures  for  the  various 
I/O  devices. 


Card  Input  — Design  Description 


Card  decks  submitted  by  the  user  are  identified  by  two  header 
cards:  a user  ID  card  and  a deck  ID  card.  The  user  ID  card  or  cards 

contain  the  user's  name,  his  project  and  the  deck  access  class.  The 
deck  ID  card  contains  the  name  of  the  deck  and  the  name  of  the  system 
process  to  be  used  for  reading  the  deck.  In  addition  a unique  identi- 
fier card,  supplied  by  the  operator,  is  inserted  before  and  after  each 
card  deck  to  ensure  that  each  user  deck  is  read  separately.  A card 
reader  driver  process  reads  in  the  card  decks  and  places  them  into  a 
segment  in  the  card  pool  hierarchy.  The  driver  process  has  no  special 
privileges.  Therefore  all  decks  must  have  an  access  class  identical 
to  the  authorization  of  the  driver  process.  The  driver  process  re- 
jects all  decks  whose  access  classes  are  not  identical.  Although  the 
driver  is  given  no  privileges  with  respect  to  the  system  security  con- 
trols, it  is  trusted  to  refuse  to  read  decks  of  the  wrong  access 
class . 


The  card  pool  hierarchy  is  a set  of  directories  and  segments  con- 
taining the  images  of  the  card  decks  read.  The  root  of  the  hierarchy 
is  an  unclassified  card  pool  directory.  Within  the  root  is  a directo- 
ry for  each  access  class  currently  required  to  store  card  decks. 

Within  each  access  class  directory  is  a directory  corresponding  to 
each  user  who  has  card  decks  in  the  pool . The  actual  card  deck  images 
are  placed  in  segments  within  these  user  directories.  To  obtain  a 
copy  of  the  card  deck  image  the  user  must  copy  the  cards  to  one  of  his 
own  segments.  A garbage  collector  removes  deck  image  segments  from 
the  card  pool  hierarchy  at  periodic  intervals. 

Card  Input  — Test  Procedures 

The  following  tests  check  for  the  proper  operation  of  the  card 
input  routines  and  related  functions.  In  general  since  the  I/O  rou- 
tines interpretively  check  the  access  class  and  ACLs,  I/O  routines 
must  function  correctly.  Therefore  the  tests  for  all  I/O  devices  in- 
clude both  security  sensitivity  tests  and  general  operational  correct- 
ness tests.  At  the  beginning  of  these  tests  the  card  reader  is  logged 
into  the  system  with  an  access  class  of  secret ,c 1 ,c2. 

CIF-1  to  CIF-6:  Security  tests. 

The  first  group  of  tests  check  for  the  proper  operation  of  the  card 
reader  with  regard  to  access  classes.  An  attempt  is  made  in  these 
tests  to  input  decks  with  different  access  classes  to  ensure  that 
only  decks  with  an  access  class  equal  to  the  access  class  of  the 
card  reader  are  read  into  the  system.  The  relationships  between  the 
access  class  of  the  six  decks  (D)  and  the  access  class  of  tne  card 
reader  (Crt)  are  the  same  as  those  in  the  directory  tests  DSC-1  to 
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DSC-6,  and  are  indicated  in  the  table  below. 

user. project  deck  access  class  relation  result 


CIF-1 

u7.p5 

S,c1 ,c2 

D = CR 

deck  accepted 

CIF-2 

u6  .p5 

U,c1 ,c2 

D < CR 

deck  rejected 

CIF-3 

u6  .p5 

S,c1 

D 6 CR 

deck  rejected 

CIF-4 

u6.p5 

S,c1 ,c2,c3 

CR  S D 

deck  rejected 

CIF-5 

u6.p5 

T,c 1 ,c2 

D > CR 

deck  rejected 

CIF-6 

u6.p5 

S,c3 

D i CR 

deck  rejected 

CIF-7:  Unique  ID  Card  test. 


Card  decks  must  be  surrounded  by  identical  unique  identifiers.  In 
this  test  a card  deck  is  surrounded  by  unique  identifiers  that  are 
different.  The  deck  should  be  rejected  and  the  operator  notified. 

CIF-8  to  CIF-12:  User  ID  card  tests. 

The  following  five  tests  check  the  validity  of  the  user  ID  card. 

The  first  test,  CIF-8,  cnecks  that  the  user  ID  card  is  properly  read 
if  the  access  class  is  expanded  over  more  than  one  card.  The  second 
test  of  this  group,  CIF-9,  ensures  that  a deck  is  rejected  if,  while 
the  access  class  of  the  card  reader  is  not  unclassified,  the  access 
class  field  of  the  user  ID  card  is  omitted.  Following  test  CIF-9 
the  access  class  of  the  card  reader  is  changed  to  unclassified.  The 
next  test  CIF-10  checks  to  ensure  that  a card  deck  with  no  access 
class  on  the  user  ID  card  is  properly  read  while  the  access  class  of 
the  card  reader  is  unclassified.  Test  Cl F— 1 1 checks  that  an  invalid 
access  class  on  the  user  ID  card  is  rejected  by  the  card  reader. 

The  final  test  of  this  series,  test  CIF-12,  checks  that  a * cannot 
be  placed  in  the  user  field  of  the  user  ID  card.  The  table  below 
outlines  the  user  ID  card  tests. 

user  ID  card(s)  results 


CIF-8:  u7.p5  secret, 

c1,c2;  deck  accepted 

CIF-9:  u6.p5;  deck  rejected 

***  (Change  level  of  card  reader  to  unclassified)  *** 

CIF-10:  u7.p5;  deck  accepted 

CIF-11:  u6.p5  unsecret;  deck  rejected 

CIF-12:  *.p5;  deck  rejected 

CIF-1 3 and  CIF-14:  Deck  ID  card  tests. 

These  tests  check  the  validity  of  the  deck  ID  card.  The  tests  con- 
tinue to  assume  that  the  access  class  of  the  card  reader  is 
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unclassified.  On  the  deck  ID  card,  the  user  is  allowed  to  specify 
the  name  of  a device  interface  module  (DIM),  which  is  the  name  of 
tne  program  that  will  read  and  perform  code  conversion  on  his  card 
deck.  Test  C I F— 1 3 checks  that  a deck  having  a non-system  DIM  name 
on  the  deck  ID  card  is  rejected  and  the  operator  notified,  thus  en- 
suring that  users  can  not  specify  their  own  card  reading  routines. 

In  test  CIF-1 4 a deck  is  read  with  the  same  user  and  deck  ID  cards 
as  test  CIF-10.  This  test  ensures  that  decks  with  identical  names 
are  named  differently  in  the  system. 

CIF-15  to  CIF-23--  Tests  on  results. 

If  tests  CIF-1  to  CIF-1 4 have  been  performed  correctly  four  decks 
have  been  read  into  fiultics  through  the  card  reader.  The  following 
tests  check  the  results  to  ensure  that  the  card  reader  routines  are 
functioning  properly.  User  u7  is  used  in  all  the  seven  tests. 

Tests  CIF-15  to  CIF-18  ensure  that  the  card  decks  read  by  the  card 
reader  are  properly  placed  in  the  card  pool  hierarchy.  In  test 
CIF-15  the  user  lists  the  card  pool  directory  to  ensure  that  there 
are  two  directories:  one  corresponding  to  unclassified  and  one  cor- 
responding to  secret, cl ,c2.  Test  CIF-16  then  lists  the  directory 
corresponding  to  secret, cl, c2  to  ensure  that  there  is  a directory 
entry  for  user  u7  and  no  entry  for  user  u6.  Test  CIF-17  lists  user 
u7's  directory  to  ensure  that  there  are  two  segments  corresponding 
to  the  decks  read  in  tests  CIF-1  and  CIF-8.  The  final  test  of  tnis 
group  CIF-18  prints  the  segment  created  by  test  CIF-1  to  ensure  that 
the  deck  has  been  read  properly.  Following  is  a summary  of  these 
tests . 


user .project 

operation 

result 

CIF-15: 

: u7.p5 

list 

card_pool  directory 

unclassified  directory 
S,c1 ,c2  directory 

CIF-16 

: u7.p5 

list 

S,c1 ,c2  directory 

directory  for  u7 

CIF-17 

: u7.p5 

list 

directory  for  u7 

segment  for  test  CIF-1 
segment  for  test  CIF-8 

CIF-18 

: u7.p5 

print  segment  for 
test  CIF-1 

segment  from 
test  CIF-1 

In  tests  CIF-19  to  CIF-22  the  access  control  lists  of  the  directory 
and  segments  in  the  card  pool  are  checked.  Test  CIF-19  checks  the 
access  control  list  for  the  card  pool  directory  to  ensure  that  no 
user  has  modify  permission  to  the  card  pool.  Test  CIF-20  lists  the 
access  control  list  for  the  directory  corresponding  to  secret, cl, c2 
to  ensure  that  no  user  has  modify  permission  to  this  directory. 

Test  CIF-21  checks  the  access  control  list  for  the  directory  created 
by  user  u7*s  card  decks  to  ensure  that  only  user  u7  has  status  per- 
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mission  to  this  directory  and  to  ensure  that  no  user  has  modify  per- 
mission. Finally  test  CIF-22  checks  the  access  control  list  for  the 
segment  corresponding  to  the  deck  read  in  test  CIF-1  to  ensure  that 
read  permission  for  u7.p5  is  the  only  user  permission  granted.  The 
following  table  summarizes  tests  CIF-19  to  CIF-22. 


user .project 


ACL  listed 


result 


CIF-19:  u7.p5 
CIF-20 : u7.p5 
CIF-21:  u7.p5 


card  pool  directory 
S,c1 ,c2  directory 
u7's  directory 


CIF-22:  u7.p5 


segment  corresponding 
to  test  CIF-1 


no  user  has  modify 
no  user  has  modify 
only  u7.p5  has  status 
no  user  has  modify 
u7.p5  has  read 
no  other  user  privileges 


In  the  final  test  of  this  group,  CIF-23t  user  u7  uses  the  copy_cards 
com  land  to  copy  the  unclassified  file  read  in  test  CIF-10.  User  u7 
should  be  notified  of  the  existence  of  two  copies  of  the  file  and 
the  copy  request  should  be  properly  performed. 


CIF-24:  Test  of  I/O  attachment. 


The  security  controls  are  effective  only  if  attachment  of  devices  is 
controlled  by  the  operating  system.  Attachment  of  devices  on  .lul- 
tics  is  done  by  calling  the  ioi_  primitive,  which  is  a gate  into 
ring  zero.  Test  CIF-24  checks  the  access  control  list  of  ioi_  to 
ensure  that  no  user  may  call  ioi_$attach.  Though  this  test  is  not 
strictly  a card  input  test,  it  is  performed  here  because  it  applies 
to  all  I/O  devices. 


Following  these  tests  the  operator  should  delete  the  directories  in 
the  card  pool  for  user  u7  so  that  future  tests  will  perform  properly. 


Card  Output  — Design  Description 


Card  output,  as  well  as  printed  output  and  most  other  I/O,  is 
performed  by  a system  process  called  an  I/O  daemon.  (Card  input  is 
performed  by  a different  type  of  daemon.)  An  I/O  daemon  is  a system 
process  that  handles  I/O  requests.  There  are  usually  several  I/O  dae- 
mons logged  into  the  system  at  any  one  time.  There  are  two  basic 
types  of  I/O  daemons:  the  I/O  coordinator,  of  which  there  is  only  one 

per  system,  and  an  I/O  driver  process,  of  which  tnere  is  one  per  de- 
vice. The  I/O  coordinator  has  special  privileges  with  respect  to  se- 
curity. The  driver  process  have  no  special  privileges  other  than  the 
right  to  attach  I/O  devices. 


To  punch  a deck  a user  sends  a message  to  the  I/O  coordinator 
stating,  among  other  things,  the  pathname  of  the  segment  to  be 
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punched.  The  I/O  coordinator  forwards  the  request  to  the  driver  pro- 
cess for  the  first  available  card  punch  that  can  handle  the  request. 

The  card  punch  driver  can  accept  requests  within  a range  of  ac- 
cess classes.  The  maximum  access  class  is  the  authorization  at  which 
the  driver  operates.  The  I/O  coordinator  only  forwards  requests  to 
the  drivers  if  the  requests  have  an  access  class  between  the  minimum 
and  maximum  access  class  associated  with  the  device.  The  access  class 
of  a particular  request  is  the  authorization  of  the  process  that  made 
tne  request  — not  the  access  class  of  the  segment  to  be  punched. 

To  limit  overclassification  by  the  card  punch  an  access  class 
banner  is  punched  with  each  deck.  The  access  class  banner  is  the 
least  access  class  that  is  greater  than  or  equal  to  both  the  authori- 
zation of  the  user  process  requesting  the  output  and  the  minimum  ban- 
ner for  the  device. 

Card  Output  — Test  Procedures 

Tne  following  tests  check  for  the  proper  operation  of  the  card 
punch  routines  and  related  functions.  Throughout  these  tests  the  card 
punch  is  assumed  to  have  been  logged  in  with  the  parameters  specified 
at  initialization.  These  parameters  are  as  follows: 

maximum  access  class  = secret.cl ,c2,c3,c4 
minimum  banner  r restricted ,c 1 ,c2,c3 

minimum  access  class  = confidential ,c 1 ,c2 

CPT-1  to  CPT-6:  Security  tests. 

The  first  group  of  tests  for  the  card  punch  ensure  that  to  punch  a 
segment  the  process  making  the  request  must  have  an  authorization  in 
the  range  of  the  device.  For  each  test  a process  of  a different  au- 
thorization attempts  to  punch  an  unclassified  segment.  In  the  table 
below,  P is  the  authorization  of  the  process  and  Min  and  Max  are  the 
minimum  and  maximum  access  classes  of  the  device  respectively. 


user. project  process  authorization  relation  result 


CPT-1 

u7.p5 

C,c 1 ,c2 

P = 

Min 

deck 

punched 

CPT-2 

U7.P5 

U,c  1 ,c2 

P < 

Min 

no 

deck 

punched 

CPT-3 

u7.p5 

C,c  1 

p e 

Min 

no 

deck 

punched 

CPT-4 

u7  .p5 

C,c1 ,c2,c3,c4,c5 

Max 

6 P 

no 

deck 

punched 

CPT-5 

u7.p5 

T,c 1 ,c2 

P > 

Max 

no 

deck 

punched 

CPT-b 

u7.p5 

C,c2,c3 

P i 

Min 

no 

deck 

punched 
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CPT-7  to  CPT-9:  Improper  access  checks. 

Tests  CPT-7  to  CPT-9  check  that  the  interpretive  checks  of  the  ac- 
cess class  of  the  segment  and  the  access  control  list  are  made  cor- 
rectly by  the  driver  or  I/O  coordinator.  Before  punching  it  must  be 
verified  that  the  process  that  made  the  request  had  the  proper  au- 
thorization and  was  listed  on  the  ACL  of  the  segment  to  be  punched. 
Normally,  these  checks  are  made  at  the  time  of  request  by  the  dpunch 
command  in  the  user  ring.  In  order  to  verify  that  the  checks  are 
made  by  the  I/O  daemon,  a special  version  of  the  dpunch  command  is 
used  for  these  tests  that  does  not  make  any  access  checks  before 
queuing  the  request. 

In  test  CPT-7  a process  with  a confidential ,c 1 ,c2  authorization  at- 
tempts to  punch  a segment  with  a secret, c1,c2  access  class.  The 
output  should  not  be  punched  and  the  operator  should  be  notified  of 
tne  improper  request. 

In  test  CPT-8  a process  with  a confidential , cl ,c2  authorization  at- 
tempts to  punch  a segment  with  a confidential , cl ,c2,c3  access  class. 
The  segment  should  not  be  punched  and  the  operator  should  be  noti- 
fied of  an  improper  request. 

For  test  CPT-9  an  attempt  is  made  to  punch  a segment  to  which  the 
user  does  not  have  read  access  on  the  ACL.  The  segment  should  not 
be  punched  and  an  error  message  should  be  produced. 

CPT-10  and  CPT-11:  Banner  checks. 

Tests  CPT-10  and  CPT-11  check  the  banner  for  the  card  punch.  Test 
CPT-10  tests  the  minimum  banner  of  the  device.  Test  CPT-11  ensures 
that,  if  the  access  class  of  the  process  making  the  request  is 
greater  than  the  minimum  banner,  the  authorization  of  the  process  is 
used  as  the  banner. 

user. project  process  authorization  banner 


CPT-10:  u7.p5  C,c1,c2  R,c1,c2,c3 

CPT-11:  u7.p5  S,c1 ,c2,c3,c4  S,c1 ,c2,c3,c4 

Following  these  tests  the  operator  should  clear  the  queues  of  the  re- 
quests made  in  tests  CPT-2  through  CPT-6. 

Printed  Output  — Design  Description 

Local  and  remote  line  printers,  like  card  punches,  are  run  by 
system  I/O  daemons.  Each  printer  has  a maximum  access  class  that  is 
the  maximum  access  class  of  data  that  can  be  printed,  a minimum  access 


class  that  is  the  minimum  authorization  of  a process  that  can  request 
data  to  be  printed  on  that  printer,  and  a minimum  banner  that  is  the 
minimum  access  class  name  appearing  in  block  letters  on  the  first  page 
of  output  of  each  segment  printed.  Along  with  each  printer,  there  is 
an  accountability  terminal  that  is  used  to  print  an  accountability 
form1"-  for  each  segment  printed  on  the  printer. 

In  addition  to  the  security  controls  mentioned,  the  user  has  the 
ability  to  print  access  class  labels  at  the  head  and  foot  of  each  page 
of  output.  These  labels  cannot  be  trusted  to  display  correctly  the 
access  class  of  the  data  since  the  user  can  change  them.  However, 
they  do  provide  a framework  for  per  page  classification. 

Printed  Output  — Test  Procedures 

The  following  tests  check  for  the  proper  operation  of  the  printer 
routines  and  related  functions.  The  first  eleven  tests  are  identical 
to  the  tests  performed  for  the  card  punch.  The  two  printers  prtl  and 
prt2  are  assumed  to  be  initialized  as  indicated  in  the  table  on  page 
34.  For  tests  LPT-1  to  LPT-16  and  tests  LPT-20  to  LPT-22  a single 
printer  prtl  is  used  having  the  following  parameters: 

maximum  access  class  = secret, cl ,c2,c3,c4 
minimum  banner  = restricted ,c 1 ,c2,c3 

minimum  access  class  = confidential , cl ,c2 

Tests  LPT-17  to  LPT-19  require  both  printers.  The  second  printer, 
prt2,  has  the  following  parameters: 

maximum  access  class  = top  secret, cl ,c2,c3,c4,c5 
minimum  banner  = top  secret, cl ,c2,c3,c4 

minimum  access  class  = secret, cl ,c2,c3,c4 

LPT-1  to  LPT-6:  Security  tests. 

The  first  group  of  tests  for  the  printer  ensure  that  to  print  a seg- 
ment a process  must  have  an  authorization  in  the  range  specified  for 
the  printer.  For  each  test  a process  of  a different  authorization 
attempts  to  print  an  unclassified  segment.  The  table  below  outlines 
the  security  tests. 


1 2 

Accountability  forms,  e.g.  AF  form  310,  are  required  by  the  mili- 
tary for  each  classified  document  produced. 
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user .project 

process  authorization 

relation 

result 

LPT-1 

u7.p5 

C,c1 ,c2 

P = 

Min 

segment 

printed 

LPT-2 

u7.p5 

U,c1  ,c2 

P < 

Min 

no 

segment 

printed 

LPT-3 

u7  .p5 

C,c  1 

p e 

Min 

no 

segment 

printed 

LPT- 4 

u7.p5 

C,c1 ,c2,c3,c4,c5 

Max 

6 P 

no 

segment 

printed 

LPT-5 

u7.p5 

T,c1  ,c2 

P > 

Max 

no 

segment 

printed 

LPT-  C 

u7.p5 

C,c2,c3 

P i 

Min 

no 

segment 

printed 

LPT-7  to  LPT-9:  Improper  access  checks. 

Tests  LPT-7  to  LPT-9  check  that  the  printer  driver  and  I/O  coordina- 
tor perform  the  interpretive  checks  for  the  access  class  of  the  seg- 
ment and  access  control  list  correctly.  Before  printing  it  must  be 
ensured  that  the  process  that  requested  the  output  had  the  proper 
authorization.  As  for  the  card  punch  tests,  a special  version  of 
the  dprint  command  is  used  that  does  not  check  for  proper  access  be- 
fore queuing  the  request. 

In  test  LPT-7  a process  with  a confidential, cl ,c2  authorization  at- 
tempts to  print  a segment  with  a secret, c1,c2  access  class.  The 
output  should  not  be  produced  and  the  operator  should  be  notified  of 
the  improper  request. 

In  test  LPT-8  a process  with  a confidential ,c 1 ,c2  authorization  at- 
tempts to  print  a segment  with  a confidential, cl ,c2,c3  access  class. 
The  segment  should  not  be  printed  and  the  operator  should  be  noti- 
fied . 

In  test  LPT-9  an  attempt  is  made  to  print  a segment  to  which  the 
user  does  not  have  read  access.  The  segment  should  not  be  printed, 
but  instead  an  error  message  should  be  produced. 

LPT-10  and  LPT— 11:  Banner  checks. 

Tests  LPT-10  and  LPT— 1 1 check  the  banner  for  the  printer.  Test 
LPT-10  tests  the  minimum  banner  of  the  device.  Test  LPT-1 1 ensures 
that  the  process  authorization  is  used  as  the  banner  in  the  case 
wnere  the  process  making  the  request  has  an  authorization  greater 
than  the  minimum  banner. 

user. project  process  authorization  banner 


LPT-10:  u7.p5  C,c1,c2  R,c1,c2,c3 

LPT— 1 1 : u7.p5  S,c1 ,c2,c3,c4  S,c 1 ,c2,c3,c4 
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LPT-12  to  LPT-16:  Header  and  footer  tests. 


'I 


Each  page  of  printed  output  has  page  label  fields  which,  unlike  the 
banners,  are  placed  at  the  discretion  of  the  user.  The  fields  con- 
sist of  character  strings  appearing  at  the  top  and  bottom  of  each 
page  of  printout.  The  user  can  either  explicitly  specify  the  con- 
tents of  these  labels,  or  he  can  specify  as  a default  that  the  la- 
bels indicate  the  access  class  of  the  segment.  Although  these  dis- 
cretionary labels  cannot  be  trusted,  users  may  rely  on  them  to  dis- 
play correctly  the  access  class  of  the  data.  Thus,  tests  for  the 
correct  functioning  of  the  page  labels  are  necessary. 

Test  LPT-12  checks  the  default  label  option  to  ensure  the  segment's 
access  class  is  used  for  the  header  and  footer  label  for  each  page 
of  output.  Test  LPT- 13  checks  the  access  class  option  to  ensure 
that  the  access  class  of  the  segment  is  used  for  the  header  and 
footer  labels.  Test  LPT-14  checks  the  label  option  to  ensure  that 
the  user-supplied  character  string  is  used  as  the  header  and  footer 
label  for  each  page  of  printed  output.  LPT-15  checks  the  top  label 
option  to  ensure  that  the  user  supplied  character  string  appears 
only  on  the  top  of  each  page  while  the  bottom  label  is  the  segment's 
access  class.  The  corresponding  bottom  label  option  is  tested  in 
test  LPT-16.  Following  is  a summary  of  the  header  and  footer  tests. 


option 

top  label 

bottom  label 

LPT-12 

default 

segment  access 

class 

segment  access 

class 

LPT- 13 

-access_class 

segment  access 

class 

segment  access 

class 

LPT-14 

-label 

user  supplied 

label 

user  supplied 

label 

LPT-15 

-top_label 

user  supplied 

label 

segment  access 

class 

LPT-16 

-bottom_label 

segment  access 

class 

user  supplied 

label 

LPT-17  to  LPT-19:  Queue  group  tests. 

This  group  of  tests  checks  the  proper  operation  of  queue  groups.  A 
queue  group  is  a collection  of  devices  that  share  a queue  of  re- 
quests. Since  each  request  in  a queue  may  have  a different  access 
class,  it  is  necessary  to  check  that  each  request  in  a queue  is  sent 
only  to  the  device  that  can  accept  it  according  to  the  device's  ac- 
cess class  range.  The  queue  groups  are  used  for  other  devices  be- 
sides printers,  but  the  test  is  made  only  for  printers  because  the 
software  in  the  I/O  coordinator  is  identical  for  all  device  types. 

A second  printer  initialized  as  prt2  is  needed  for  these  tests. 

Test  LPT-17  tests  the  proper  operation  of  the  queue  group  by  submit- 
ting two  simultaneous  dprint  requests  thus  forcing  a segment  to 
print  on  each  printer.  Test  LPT-18  ensures  that  if  a request  has  a 
level  greater  than  that  of  one  device  in  the  queue  it  will  be  print- 
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ed  by  anotner  device  in  the  queue  having  the  proper  level.  This 
test  is  constructed  so  that,  if  level  checks  were  improperly  made  or 
ignored,  the  segment  would  be  printed  on  the  wrong  printer.  Test 
LPT-19  is  identical  to  test  LPT-18  except  that  the  category  set  is 
greater  rather  than  the  level. 

LPT-20  to  LPT-22:  Accountabili ty  terminal  tests. 

With  each  printed  output  an  accountability  form  is  printed.  This 
form  is  used  to  interface  the  computer's  internal  security  controls 
with  the  external  environment.  The  accountability  form  contains 
pertinent  information  regarding  security  and  must  be  checked  for 
correctness.  Test  LPT-20  checks  the  correctness  of  each  accounta- 
bility form  produced  in  the  previous  tests.  The  checks  include  cor- 
rectness checks  for  the  proper  user  name,  user  project,  proper  date 
and  time,  pathname  of  the  segment  printed,  sequence  number,  and  the 
access  class  of  the  segment.  Test  LPT-21  ensures  that  a printer  re- 
quiring an  accountability  terminal  will  not  perform  output  if  its 
accountability  terminal  is  not  dialed  up.  The  final  test  LPT-22  en- 
sures that,  should  an  accountability  form  terminal  be  disconnected 
during  printing,  the  printer  will  cease  to  accept  output  requests. 
This  feature  guarantees  that  the  number  of  forms  printed  will  be 
equal  to  the  number  of  requests  printed. 

Following  the  completion  of  the  above  tests  the  operator  should  delete 
any  requests  remaining  in  the  queues  as  a result  of  tests  LPT-2  to 
LPT- 6 and  LPT-22. 


Tape  I/O  — Design  Description 

Magnetic  tape  input  and  output  is  also  performed  by  I/O  daemons. 
Currently  however,  the  majority  of  the  security  controls  are  manually 
performed  by  the  operator.  Future  releases  of  the  system  are  planned 
to  integrate  some  of  the  security  controls  into  the  system  to  simplify 
the  operator's  interface. 

All  magnetic  tapes  used  on  the  system  are  registered  and  assigned 
an  access  class.  When  a user  desires  to  read  or  write  a tape  he  exe- 
cutes a read_tape  or  write_tape  command.  The  command  adds  the  request 
to  a queue  and  notifies  the  operator  of  the  request.  The  operator 
must  assign  the  tape  drive,  mount  the  tape,  verify  that  the  user  has 
the  need-to-know  to  read  or  write  the  tape,  and  verify  that  the  user's 
authorization  allows  him  the  requested  access.  The  operator  assigns 
the  access  class  of  the  drive  to  be  the  same  as  the  access  class  of 
the  tape.  Tapes  may  be  read  into  a specified  segment  or  into  a tape 
pool  hierarchy,  similar  to  the  card  pool  hierarchy.  Any  segment  that 
the  user  can  read  may  be  written  onto  a tape. 
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One  disadvantage  with  the  current  system  is  that  there  is  no 
means  by  which  the  system  can  differentiate  between  tape  drives  as- 
signed for  reading  and  those  assigned  for  writing.  The  result  of  this 
restriction  is  that  the  minimum  and  maximum  access  classes  of  the  tape 
daemon  must  be  identical.  The  operator  must  ensure  that  this  require- 
ment is  met.  The  minimum  banner  parameter  has  no  effect  on  tape 
drives . 

Tape  I/O  — Test  Procedures 

The  following  tests  check  for  the  proper  operation  of  the  tape 
input  and  output  routines  and  related  functions.  The  tape  pool  hier- 
archy is  not  tested  here  as  it  is  identical  to  the  card  pool  hierarchy 
tested  in  card  input  and  is  managed  by  the  same  software.  In  addi- 
tion, only  the  software  is  tested.  Checks  performed  by  the  operator 
as  described  above  are  not  tested.  The  tests  TDT-1  to  TDT-9  below  ap- 
ply to  tape  output,  and  TDT-10  and  TDT-1 8 are  for  tape  input. 
Throughout  these  tests  the  magnetic  tape  drive  is  assumed  to  have  been 
initialized  for  reading  and  writing  at  the  access  class 
confidential ,c1 ,c2. 

TDT-1  to  TDT-6:  Security  tests  for  writing  a tape. 

The  first  group  of  tests  for  tape  output  ensures  that  the  process 
requesting  the  writing  of  a tape  has  an  authorization  equal  to  that 
of  the  device.  For  each  test  a process  of  a different  authorization 
attempts  to  write  an  unclassified  segment  onto  tape.  In  the  table 
below,  TD  is  the  access  class  of  the  tape  drive. 


user .project 

process  authorization 

relation 

result 

TDT-1 

u7.p5 

C,c1 ,c2 

P = TD 

tape 

written 

TDT-2 

u7.p5 

U,c1 ,c2 

P < TD 

no 

tape 

written 

TDT-3 

u7.p5 

C,c  1 

P 6 TD 

no 

tape 

written 

TDT-4 

u7.p5 

C,c 1 ,c2,c3,c4,c5 

TD  6 P 

no 

tape 

written 

TDT-5 

u7.p5 

T,c 1 ,c2 

P > TD 

no 

tape 

written 

TDT-6 

u7.p5 

C,c2,c3 

P i TD 

no 

tape 

written 

Note  again  that  there  is  no  check  for  the  access  class  of  the  tape 
itself.  That  must  be  verified  by  the  operator. 

TDT-7  to  TDT-9:  Improper  access  checks  for  writing  a tape. 


Tests  TDT-7  to  TDT-9  check  that  the  tape  driver  and  the  I/O  coordi- 
nator perform  the  interpretive  check  for  the  access  class  of  the 
segment  and  access  control  list  correctly.  Before  writing  a tape  it 
must  be  ensured  that  the  process  requesting  the  writing  of  the  tape 
has  an  authorization  equal  to  the  access  class  of  the  tape  drive  and 
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driver  process.  It  must  also  be  verified  that  the  access  control 
list  of  the  segment  to  be  read  allows  the  requestor  access  to  the 
segment.  For  these  tests,  a special  version  of  the  write_tape  com- 
mand is  used  that  does  not  check  for  access,  but  submits  the  request 
in  all  cases. 

In  test  TDT-7  a process  with  a confidential , cl ,c2  authorization  at- 
tempts to  write  onto  a confidential , c 1 ,c2  tape  a segment  with  a 
secret, c1,c2  access  class.  The  tape  should  not  be  written  and  the 
operator  should  be  notified  of  the  improper  request. 

In  test  TDT-8  a process  with  a confidential ,c 1 ,c2  authorization  at- 
tempts to  write  onto  a confidential , cl ,c2  tape  a segment  with  a 
confidential , cl ,c2,c3  access  class.  The  tape  should  not  be  written 
and  the  operator  should  be  notified. 

In  test  TDT-9  an  attempt  is  made  to  write  onto  a tape  a segment  to 
which  the  user  does  not  have  read  access.  The  segment  should  not  be 
written  and  an  error  message  should  be  produced. 

TDT-10  to  TDT-1 5:  Security  tests  for  reading  a tape. 

The  first  group  of  tests  verifies  that  to  read  a tape  the  process 
making  the  request  must  have  an  authorization  equal  to  that  of  the 
tape  drive.  For  each  test  a process  of  a different  authorization 
attempts  to  read  a tape.  The  table  below  outlines  the  security 
tests . 


user .project 

process  authorization 

relation 

result 

TDT-10 

u7  -p5 

C,c  1 ,c2 

P = TD 

tape 

read 

TDT-1  1 

u7.p5 

U,c 1 ,c2 

P < TD 

no 

tape 

read 

TDT-1  2 

u7  .p5 

C,c  1 

P G TD 

no 

tape 

read 

TDT-1  3 

u7.p5 

C,c 1 ,c2,c3.c4,c5 

TD  6 P 

no 

tape 

read 

TDT-1 4 

u7  .p5 

T,c  1 ,c2 

P > TD 

no 

tape 

read 

TDT-1 5 

u7  .p5 

C,c2,c3 

P i TD 

no 

tape 

read 

TDT-16  to  TDT-18:  Improper  access  checks  for  the  tape  reader. 

Tests  TDT-16  to  TDT-18  verify  that  the  interpretive  access  class  and 
access  control  list  checks  are  made  properly,  in  a manner  similar  to 
that  for  the  other  devices. 

In  test  TDT-16  a process  with  a confidential ,c 1 ,c2  authorization  at- 
tempts to  read  a tape  into  a secret, cl, c2  access  class  segment.  The 
operator  should  be  notified  of  the  improper  request. 
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In  test  TDT-17  a process  with  a confidential , cl ,c2  authorization  at- 
tempts to  read  a tape  into  a confidential , cl ,c2,c3  segment.  The  op- 
erator should  again  be  notified. 

In  test  TDT-18  a process  not  having  write  access  to  a segment  at- 
tempts to  read  a tape  into  that  segment.  An  error  message  should  be 
produced  and  no  tape  should  be  read. 

TDT-19:  Check  of  data  read  and  written. 

For  this  test  the  segment  created  as  a result  of  reading  the  tape  in 
test  TDT-10  is  printed.  This  test  ensures  that  both  the  write_tape 
command  (which  originally  was  used  to  write  the  tape  in  TDT-1)  and 
read_tape  command  are  functioning  correctly. 

Following  these  tests  the  operator  should  delete  from  the  queues  re- 
quests generated  as  a result  of  tests  TDT-2  through  TDT-6  and  TDT-1 1 
through  TDT-1 5. 


SYSTEM  SECURITY  ADMINISTRATOR 


Design  Description 


The  System  Administrator  is  an  individual  who  has  access  to  cer- 
tain administrative  commands  and  data  bases  in  Multics,  such  as  the 
PNT,  SAT,  etc.  The  normal  System  Administrator  can  carry  out  his 
functions  without  regard  to  security  controls,  and  his  functions  are 
not  affected  by  the  addition  of  security  controls.  The  System  Securi- 
ty Administrator  is  the  only  individual  who  is  permitted  to  perform 
certain  security  related  operations  within  the  hierarchy,  such  as  the 
reclassification  of  segments  and  directories,  that  may  occasionally  be 
required.  Because  of  the  sensitive  nature  of  his  operations,  the  SSA 
is  only  given  a special  limited  subset  of  available  Multics  commands 
required  to  perform  his  functions  (see  the  discussion  of  system  proc- 
esses on  page  19).  He  is  not  permitted  to  call  most  of  the  user  com- 
mands, nor  can  he  arbitrarily  invoke  other  users'  programs.  The  com- 
plete set  of  commands  available  to  the  SSA  is  determined  by  the  in- 
stallation, but  there  are  certain  commands  that  have  been  especially 
designed  for  use  by  SSAs.  .these  are: 


reclassify_dir 
reclassify_seg 
reclassify_sys_seg 
reset_soos 
set_system_pi  *v 


upgrade/downgrade  a directory 
upgrade/downgrade  a segment 
upgrade/downgrade  a ring  1 segment 
reset  security  out  of  service  bit 
set/reset  system  privilege  bits 
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In  order  to  use  any  of  these  commands,  and  to  perform  certain  other 
functions  that  may  be  illegal  for  the  average  user,  the  SSA  is  given 
access  to  a special  "system_privilege_"  gate  into  hardcore  that  is 
used  to  set  or  reset  certain  per  process  privilege  bits.  Each  privi- 
lege bit  allows  the  current  process  to  bypass  the  security  controls 
when  performing  operations  in  a certain  area.  There  are  five  privi- 
lege bits: 

dir  directory  privilege 

seg  segment  privilege 

ipc  IPC  privilege 

ringl  ring  1 privilege 

soos  security  out  of  service  privilege 

The  first  three  bits  — dir,  seg,  ipc  --  can  be  set  to  bypass  all  se- 
curity related  checks  with  respect  to  directories,  segments,  and  IPC. 
For  example,  with  the  directory  privilege  set,  the  user  can  list  the 
contents  of  directories  of  a higher  access  class  than  the  current  au- 
thorization. With  the  IPC  privilege,  IPC  messages  can  be  received  and 
sent  to  processes  of  all  authorizations.  The  ringl  privilege  bit 
specifies  that  security  checks  performed  in  ring  1 subsystems  be  by- 
passed. The  soos  privilege  bit  causes  the  security  out  of  service 
flag  to  be  ignored  when  the  process  performs  operations  on  directories 
and  segments. 

The  security  out  of  service  bit  is  set  in  a directory  or  segment 
whenever  the  system  detects  an  inconsistency  in  the  hierarchy.  One 
example  is  a directory  whose  access  class  is  not  greater  than  or  equal 
to  the  access  class  of  its  parent.  When  the  security  out  of  service 
bit  is  set,  the  directory  or  segment  cannot  be  accessed  by  any  process 
until  the  bit  is  reset,  except  for  the  special  case  of  a process  with 
the  soos  privilege  bit  set. 

The  first  four  SSA  commands  listed  above  are  used  to  perform  "re- 
pair" type  operations  in  the  hierarchy.  The  set_system_priv  command 
can  explicitly  set  or  reset  any  of  the  five  system  privilege  bits,  so 
that  certain  "normal"  user  commands,  such  as  delete,  move_quota,  etc., 
can  be  used  by  the  SSA  without  interference  from  the  security  con- 
trols, The  set  of  "normal"  user  commands  available  to  the  SSA  should 
be  small  to  minimize  the  possibility  of  human  error  or  a Trojan  Horse 
resulting  in  a compromise  of  security. 

Test  Procedures 


In  order  to  be  reasonably  certain  that  the  commands  used  by  the 
SSA  work  as  expected,  it  would  be  necessary  to  test  every  command 
available  to  him.  This  is  not  possible,  however,  since  his  set  of 
commands  is  not  explicitly  defined  — any  Multics  command  could  poten- 


tially  be  available  to  the  SSA  if  the  installation  chooses.  It  is 
left  up  to  the  installation  to  make  sure  that  commands  available  to 
the  SSA  work  properly  and  have  no  Trojan  Horses.  The  only  SSA  tests 
that  are  specified  here  are  the  tests  of  the  five  SSA  commands  and  the 
proper  enforcement  of  the  five  privilege  bits. 


SSA-1 : ACL  of  system_privilege_  gate. 

Probably  the  most  important  test  is  a check  that  only  the  SSA  has 
access  to  the  system_privilege_  gate.  This  test  consists  of  listing 
the  ACL  of  system__privilege_,  and  checking  to  make  sure  that  only 
the  SSA  and  perhaps  SysDaemons  have  execute  access.  The  SSA  himself 
could  make  tnis  check. 

SSA-2  to  SSA-7:  Check  of  set_system_priv  and  enforcement  of  privilege 
bits. 

These  tests  check  that  each  privilege  bit  allows  only  that  specified 
privilege  and  no  others,  and  that  the  set_system_priv  command  prop- 
erly sets  or  resets  the  privilege  desired.  For  each  of  these  tests 
a certain  configuration  of  system_privilege  bits  is  set,  and  a pro- 
gram is  called  that  attempts  to  perform  four  operations,  each  one  of 
which  is  illegal  unless  the  appropriate  privilege  bit  (dir,  seg, 
ringl  or  soos)  is  set.  Test  of  ipc  privilege  is  made  by  manually 
attempting  to  send  a message  to  another  user  logged  in  at  a lower 
authorization.  The  table  below  lists  the  arguments  passed  to 
set_system_priv,  and  the  resulting  state  of  the  privilege  bits,  for 
each  test. 

set_system_priv  privilege  bits 


SSA-2 : 

(none) 

(none) 

SSA-3 : 

dir 

dir 

SSA-1* : 

“dir  seg 

seg 

S3A-5: 

“seg  ipc 

ipc 

SSA-6: 

“ipc  ringl 

ringl 

SSA-7: 

“ringl  soos 

soos 

SSA- 8: 

“soos 

(none) 

SSA-9  to  SSA-12:  reclassify_dir , reclassify_seg,  reclassify_sys_seg, 
reset_soos  checks. 

These  four  tests  verify  that  the  four  commands  perform  as  expected. 
No  attempt  is  made  to  thoroughly  test  all  possible  cases,  but  the 
usual  use3  of  the  commands  are  checked.  For  example,  the  three  re- 
classify commands  are  checked  by  reclassifying  the  objects  and  then 
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listing  their  access  classes.  The  reset_soos  command  is  checked  by 
first  creating  an  inconsistency  in  the  hierarchy  and  thus  causing 
the  security  out  of  service  bit  to  be  set  on  a directory.  Then 
reset_soos  is  invoked  to  see  that  the  bit  is  not  reset  until  the  in- 
consistency is  corrected. 

SSA-9:  reclassify_sys_seg 

SSA-10:  reclassify _seg 
SSA-11:  reclassify_di r 
SSA-12:  reset  soos 


AUDITING 

Auditing  is  a feature  of  Multics  not  unique  to  the  security  con- 
trols. For  example,  illegal  logins,  system  errors,  etc.,  have  always 
been  audited.  With  the  addition  of  security  controls,  and  because  of 
Department  of  Defense  requirements,  certain  "normal"  events  involving 
classified  data  are  audited.  In  addition,  other  "abnormal"  events 
(faults,  access  violations)  are  also  audited,  some  to  detect  possible 
penetration  attempts  as  discussed  in  Section  II.  For  these  test  pro- 
cedures we  will  only  be  concerned  with  the  "protection  audit"  mecha- 
nism that  involves  the  additional  auditing  features  incorporated  with 
the  security  enhancements.  Auditing  of  illegal  logins  can  be  easily 
checked  by  examining  the  audit  log  after  running  the  login  tests  and 
password  validation  tests  (PAA  and  PDS  series). 

Design  Description 

The  protection  audit  mechanism  is  designed  to  audit  certain  events 
for  specific  users.  The  System  Administrator  has  a command  that  can 
set  certain  audit  bits  for  any  given  user  or  all  users  on  any  given 
project.  These  bits  specify  which  events  are  to  be  audited  in  proc- 
esses created  for  the  user  or  for  any  user  on  the  project  to  be  audit- 
ed . 


There  are  13  audit  bits  as  follows: 


seg_init 

dir_init 

mc_seg_init 

no_access 

ipr_fault 

acv_mode 

acv_ring 

no_wakeup 

sys_priv 


Segment  initiations 
Directory  initiations 
Message  segment  initiations 
Access  denied 
Illegal  procedure  faults 
Mode  access  violations 
Ring  access  violations 
Wakeup  denied 

Setting/resetting  of  system  privileges 
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ssa_ops 

no_attach 

no_mount 

mseg 


Reclassifications 
Device  attachment  denied 
RCP  mount  denied 
Message  segment  overflow 


All  audited  events  are  inserted  into  a file  called  the  syserr_log. 
The  print_syserr_log  command  can  be  used  by  the  System  Administrator 
to  select  certain  kinds  of  information  out  of  this  log. 


The  audited  events  fall  into  several  classes: 

1)  Events  that  are  legal  and  normal,  but  that  must  be  audited  for 
accountability  (seg_init,  dir_init,  mc_seg_init) . 

2)  Events  that  are  unusual  but  cannot  directly  be  exploited  if  the 
system  functions  properly  (no_access,  ipr_fault,  acv_mode, 
acv_ring,  no_wakeup,  no_attach,  no_mount). 

3)  Events  that  are  unusual  and  can  be  exploited  (mseg) . 

4)  Events  that  should  only  occur  for  the  SSA  (ssa_ops) . 

5)  Events  that  should  only  occur  for  system  processes  (SSA,  Sys- 
Daemons,  etc.). 

If  the  system  is  functioning  properly  under  normal  circumstances, 
there  will  be  many  events  in  group  2,  and  thus  it  would  probably  only 
make  sense  to  set  these  bits  on  for  certain  "suspect"  users  or  pro- 
jects. In  addition,  if  there  is  a great  deal  of  classified  proces- 
sing, there  will  be  many  events  in  group  1 (the  auditing  of  initia- 
tions only  applies  to  objects  not  at  system_low).  Events  in  groups  3, 
4 and  5 should  probably  be  audited  for  all  users,  including  the  SSA 
(but  not  SysDaemons) . Any  messages  in  group  4 or  5 can  indicate  that 
someone  has  obtained  access  to  the  system_privilege_  gate  or  obtained 
the  password  of  the  SSA.  Messages  in  group  3>  under  normal  circum- 
stances, should  occur  very  infrequently.  Many  events  in  this  group 
(caused  by  a single  user)  indicates  the  possibility  of  a penetration 
attempt . 


Test  Procedures 

Auditing  is  tested  in  a straightforward  manner.  All  audit  bits 
are  set  on  for  a given  user,  and  the  user  performs  a series  of  opera- 
tions designed  to  trigger  each  of  the  auditing  functions.  There  is  no 
test  of  the  command  used  by  the  SSA  to  set  or  reset  the  audit  bits. 

It  is  assumed  that  this  command  works  properly,  and  that  each  audit 
bit  applies  only  to  that  one  auditing  function  and  no  others.  In  or- 
der to  fully  test  auditing  the  user  must  have  access  to  the 
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systera_privilege_  gate  so  that  the  ssa_ops  audit  function  can  be  test- 
ed. Thus,  the  S3A  himself  will  probably  perform  the  tests  below.  In 
addition,  the  user  must  be  logged  in  at  an  authorization  above 
system_low . 

AUD-1  to  AUD-3:  seg_init,  dir_init,  mc_seg_init 

The  first  three  audit  bits  are  tested  simply  by  initiating  a seg- 
ment, directory,  or  message  segment  (mailbox).  Since  directories 
cannot  be  directly  initiated  by  the  user,  directory  initiation  is 
forced  by  some  reference  to  the  directory. 

AUD-M:  no_access 

This  auditing  function  is  tested  by  attempting  to  get  the  status  of 
a directory  to  which  the  user  has  no  access. 

AUD-5  to  AUD-7:  ipr_fault,  acv_mode,  acv_ring 

These  three  auditing  functions  are  invoked  when  the  user  causes  a 
fault  to  occur  by  executing  an  illegal  machine  instruction  attempt- 
ing an  illegal  access  due  to  mode  or  ring  bracket  restrictions.  To 
test  these  functions  the  user  calls  a program  that  attempts  such  op- 
erations . 

AUD-8:  no_wakeup 

In  order  to  test  this  function  a user  must  login  at  another  terminal 
with  a lower  authorization  than  the  current  user.  The  current  user 
then  attempts  to  use  the  Multics  send_message  command  to  send  that 
user  a message.  The  wakeup  signal  that  normally  occurs  should  not 
get  transmitted  (which  was  already  tested  by  the  IPC  tests)  and  the 
event  should  be  audited. 

AUD-9  and  AUD-1 0:  sys_priv,  ssa_ops 

The  ssa_ops  bit  refers  to  the  reclassify  commands  used  by  the  SSA. 

To  test  these  functions,  the  user  calls  set_system_priv  and  one  of 
the  reclassify  commands. 

AUD-1 1 and  AUD-12:  no_attach,  no_mount 

These  two  auditing  functions  are  invoked  by  attempting  an  attach  or 
mount  to  any  I/O  device.  Since  only  SysDaemons  are  allowed  to  at- 
tach or  mount  I/O  devices,  these  attempts  should  be  audited. 
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AUD-13:  mseg 


To  test  the  mseg  function,  the  max  length  of  the  user's  mailbox  is 
temporarily  set  very  small,  and  a large  message  is  sent  to  it.  A 
mailbox  overflow  occurs  and  the  event  should  be  audited. 

After  performing  the  above  tests,  the  SSA  (who  may  also  be  the  user 
making  the  tests)  uses  the  print_syserr_log  command  to  print  all  pro- 
tection audit  messages  that  occurred  since  the  beginning  of  the  audit 
tests.  The  correspondence  between  the  message  in  the  syserr  log  and 
the  command  executed  can  then  be  verified. 

: 
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SECTION  IV 
CONCLUSION 

The  security  test  procedures  are  designed  to  test  that  the  secu- 
rity enhancements  to  Multics  perform  as  required  with  respect  to  au- 
thorization and  access  class  controls.  The  areas  tested  are  those  of 
password  distribution,  process  authorization  assignment,  segment  and 
directory  access,  communication  between  processes,  I/O,  auditing,  and 
system  security  administrator  functions. 

Although  the  test  procedures  often  try  to  "subvert"  the  system  by 
attempting  illegal  operations,  no  amount  of  testing  of  a system  that 
is  not  formally  validated  will  guarantee  that  the  security  controls 
cannot  be  bypassed.  The  purpose  of  testing  is  to  give  reasonable  as- 
surance that  the  security  controls  are  invoked  where  expected,  and 
that  the  controls  function  as  expected.  This  assurance  is  important 
because  new  system  releases  are  issued  several  times  a year.  A typo- 
graphical error  or  oversight  in  coding  of  security  related  software 
should  be  detected  by  the  test  programs  --  an  obscure  design  deficien- 
cy allowing  some  peculiar  bypass  of  the  controls  will  probably  not. 
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APPENDIX  I 


TEST  ENVIRONMENT  INITIALIZATION 


The  procedure  for  initialization  of  the  test  environment  is  de- 
scribed in  this  appendix.  Refer  to  Section  III,  beginning  on  page  26, 
for  a discussion  of  this  initialization. 


USERS,  PROJECTS,  AND  TERMINALS 

The  initialization  of  these  components  of  the  test  environment 
was  described  in  detail  in  Section  III.  This  initialization  requires 
the  SA,  SSA,  and  perhaps  a user  designated  as  the  project  administra- 
tor for  the  test  projects  (who  may  be  the  SA) . The  exact  sequence  of 
commands  required  to  perform  this  initialization  is  not  given  here  be- 
cause of  the  numerous  variations  likely  to  be  encountered.  Rather, 
the  specific  attributes  of  the  users  and  projects  as  specified  in  the 
table  on  page  29  are  reproduced  here  for  convenience. 

PNT  PDT  for  pi  & p3  SAT  CDT 


u1  = C 
u2=T 
u3=S 

u4=C,1,3,4,5,6,7 

u5sC,1,3,4,5,6,7 

u6=system_high 

u7=system_high 


u 1 = S p1  = S 1 1 = C 

u2=T  p2=C  t2=T 

u3=U  p3=C, 1 ,2, 3, 4, 6, 7 t3=C, 1 ,3, 5, 6, 7 

u4=C, 1 ,2, 4, 5, 6, 7 p4=C,4,5,6  t4=C, 1 ,2, 3, 4, 5,6, 7 

u5-C, 1 ,2, 4, 5, 6, 7 p5=system_high  t5=system_high 

u6=none 

u7=none 


It  is  assumed  tnat  the  SA  and  SSA  are  familiar  enough  with  the  regis- 
tration of  new  users  and  projects  so  that  the  exact  procedure  is  obvi- 
ous. Attributes  of  the  users,  projects  and  terminals  not  specified  in 
the  table  above  are  set  to  the  default  values.  The  only  exception  is 
user  u2,  whose  PNT  entry  must  specify  that  u2  cannot  use  the 
change__password  option  in  his  login  line.  The  "generate_password"  at- 
tribute should  be  set  for  u2. 


It  may  be  that  at  the  installation  there  are  not  normally  five 
terminals  available  with  the  above  authorizations.  In  this  case  it 
may  be  necessary  for  tne  SSA  to  set  up  five  terminals  with  the  above 
authorizations  each  time  the  tests  are  run.  Actually,  the  specific 
authorizations  of  the  terminals,  projects  and  users  are  only  important 
during  the  PAA  tests.  For  other  tests,  any  terminals,  projects  or  us- 
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ers  may  be  used  that  have  a maximum  authorization  sufficient  to  per- 
form the  tests.  The  table  below  lists  the  maximum  authorizations  of 
users  required  for  each  of  the  other  test  series. 

PDS  unclassified 

SAC  unclassified 

SSC  secret, c1,c2 

DSC  secret, cl, c2 

IPC  top  secret, cl ,c2,c3 

MBX  top  secret , cl ,c2,c3 

CIF  top  secret, cl ,c2,c3 

CPT  top  secret, cl ,c2,c3,c4,c5 

LPT  top  secret, cl ,c2,c3,c4,c5 

TDT  top  secret, cl ,c2,c3,c4,c5 

SSA  (user  must  be  SSA) 

AUD  (user  must  be  SSA) 

Thus,  except  for  the  PAA  tests  which  require  users  with  specific  maxi- 
mum authorizations,  the  other  tests  may  be  performed  by  any  users  able 
to  login  at  the  authorizations  shown  in  the  table.  In  the  test 
scripts  in  Appendix  II,  users  u6  and  u7,  project  p5,  and  terminal  t5 
are  used  in  the  examples  because  they  all  have  an  authorization  of 
system_high.  For  the  PAA  tests,  users  ul  - u5,  projects  pi  - p4,  and 
terminals  tl  - t4  are  used. 


DIRECTORIES  AND  SEGMENTS 

There  are  five  special  subtrees  required  for  the  tests.  The 
first  three,  required  for  the  authorization__tester , segment  security 
controls  tests,  and  directory  tests,  are  created  by  exec_coms.  The 
fourth  subtree  for  the  I/O  tests  is  created  manually.  Any  user  with  a 
maximum  authorization  of  system_high  can  create  these  subtrees.  The 
fifth  subtree,  for  the  SSA  tests,  must  be  created  by  the  SSA.  In  the 
series  of  steps  that  follows,  it  is  assumed  that  the  user  is  initially 
logged  in  at  system_low  and  that  the  full  set  of  commands  and  subrou- 
tines for  the  test  procedures  are  available  in  the  user's  search 
rules . 

1.  Initialize  start_up.ec 

In  the  start_up.ee  in  the  user's  home  directory,  the  following  line 
should  be  inserted  to  be  executed  at  new_proc,  but  not  login  time: 

iif  [equal  &1  new_proc]  ithen  exec_com  create_test_start_up 

If  the  user  is  not  in  the  process  of  creating  test  directories,  exe- 
cution of  this  line  at  new_proc  should  have  no  effect.  Documenta- 
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tion  on  this  exec_com  can  be  found  in  Appendix  III. 

In  addition,  for  the  IPC  tests,  user  u6  must  call  the  test_ipc  com- 
mand in  his  start_up.ec  at  new_proc  time.  The  following  command 
line  should  be  inserted: 

&if  [equal  &1  new_proc]  &then  test_ipc  -go 

If  tne  user  is  not  in  the  process  of  running  the  IPC  tests,  execu- 
tion of  this  command  should  have  no  effect.  Documentation  on  the 
test_ipc  command  can  be  found  in  Appendix  III. 

2.  Initialization  of  ACL  for  authorization_tester  subtree 

Before  creating  any  directories,  it  must  be  determined  who  is  to  be 
on  the  ACLs.  The  directories  for  the  authorization_tester  should  at 
least  have  all  users  ul  through  u5  under  projects  pi  through  p4  on 
the  ACL.  However,  since  the  only  access  modes  granted  to  users  on 
the  ACLs  of  the  directories  and  segments  in  this  subtree  are  r and 
s,  there  is  no  harm  in  putting  *.*.*  on  the  ACL.  Once  the  names  of 
the  users  on  the  ACLs  have. been  determined,  a segment  called 
"create_test_acl"  should  be  created  in  the  home  directory.  This 
segment  must  contain  one  group  identifier  per  line  as  it  is  speci- 
fied for  an  ACL,  but  without  any  access  mode.  For  the 
authorization_tester  subtree,  it  is  sufficient  to  include  one  line 
in  the  segment  containing 

3.  Directory  for  authorization_tester 

Decide  on  a pathname  for  the  parent  directory  of  the  authorization 
tester  subtree  as  illustrated  in  Figure  2 and  move  sufficient  non- 
zero quota  to  it.  The  minimum  amount  of  quota  depends  on  the  number 
of  levels  and  categories  within  system_high.  The  exec_com 
"create_test_auth .ec"  should  then  be  called,  with  arguments  as  spec- 
ified in  the  writeup  of  that  exec_com  in  Appendix  III.  As  an  exam- 
ple, the  following  command  line  will  create  the  proper  subtree  for 
an  installation  where  system_high  is  T,c1 ,c2,c3,c4,c5,c6,c7: 

exec_com  create_test_auth  AUTH_TEST  "(C  R S T cl  c2  c3  c4  c5  c6  c7)" 

The  above  command  line  will  create  the  authorization_tester  subtree 
in  the  working  directory,  with  the  name  PARENT.  Creation  of  this 
subtree  will  take  quite  a while,  since  the  process  must  new_proc  to 
each  level  and  category  specified.  Each  new_proc  will  result  in  a 
message  being  printed  naming  the  current  authorization.  When  the 
command  is  completed,  the  user  will  be  returned  to  system_low  in  his 
original  working  directory. 
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4.  Initialization  of  ACL  for  directory  and  segment  test  subtrees 

The  create_test_acl  segment  in  the  home  directory  (initialized  in 
step  2 above)  should  now  be  changed  to  contain  a list  of  the  group 
identifiers  of  the  users  who  will  perform  the  directory  and  segment 
security  controls  tests  (DSC  and  SSC  series).  The  group  id  of  *.*. 
should  not  be  used,  since  modify  permission  will  be  given  to  the  us 
ers  specified.  Probably  an  identifier  like  *.SysMaint.*  and 
•.SysAdmin.*  should  be  used.  The  scripts  in  Appendix  II  use  u7  on 
project  p5  when  running  the  DSC  and  SSC  tests. 

5.  Directory  for  segment  and  directory  tests 

Decide  on  a pathname  for  the  two  directories  DIR_TEST  and  SEG_TEST, 
as  illustrated  in  Figures  3 and  4.  Move  sufficient  quota  to  the 
parents  of  these  directories,  and  execute  the  following  two 
commands : 

exec_com  create_test_dir  DIR_TEST  -acc  C,1,2  T,1,2  S,1,2  S , 1 

S, 1,2,3  S.1,3 

exec_com  create_test_seg  SEG_TEST  -acc  C , 1 , 2 T,1,2  S , 1 , 2 S , 1 

S, 1 ,2,3  S, 1 ,3 

Again,  the  above  are  just  examples  of  valid  calls  to  the  commands. 
Refer  to  the  writeups  of  create_test_dir.ec  and  create_test_seg.ec 
in  Appendix  III  for  a description  of  the  various  arguments. 

6.  Directory  for  I/O  tests 

Decide  on  a pathname  for  the  directory  IO_TEST,  as  illustrated  in 
Figure  5.  The  following  script  shows  how  to  create  the  IO_TEST  sub 
tree.  The  segment  named  10_pages  is  the  pathname  of  any  segment 
able  to  generate  at  least  ten  pages  of  printed  output.  Ready  mes- 
sages have  been  omitted. 

create_dir  IO_TEST  -quota  20 


change_wdir  I0_TEST 

qx 

a 

This  segment  cannot  be  read  due  to  a bad  read  ACL. 

\f 

w BAD_ACL 

c 

This  segment  contains  proper  information  for  output. 
\f 
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w OUTPUT 

c 

This  segment  should  not  produce  any  output. 

\f 

w NO_OUTPUT 

q 

create_dir  C,1,2  -access_class  confidential , cl ,c2  -quota  1 

create_dir  C,1,2,3  -access_class  confidential, cl ,c2,c3  -quota  1 

create_dir  S,1,2  -access_class  secret, cl ,c2  -quota  1 

copy  10_pages  LONG 

set_acl  * r *.p5.*  -sm 

delete_acl  BAD_ACL  -all 

set_acl  BAD_ACL  we  *.p5.* 

set_acl  C , 1 , 2 sma  u7.p5.* 

new_proc  -auth  confidential , cl ,c2 

change_wdir  I0_TEST>C, 1 ,2 

qx 

a 

This  segment  cannot  be  written  due  to  a bad  write  ACL 
\f 

w BAD_WRITE_ACL 

q 

delete_acl  BAD_WRITE_ACL  -all 

set_acl  BAD_WRITE_ACL  re  *.*.* 

new_proc  -auth  confidential , c 1 ,c2 ,c3 

change_wdir  I0_TEST>C, 1 ,2, 3 

qx 

a 

This  segment  should  not  be  placed  on  output  due  to  the 
process'  inability  to  read  this  segment  due  to  categories. 

\f 

w BAD  CATEGORY 


set_acl  BAD_CATEGORY  re  *.p5.* 

new_pr°c  -auth  secret, c1,c2 

change_wdir  I0_TE3T>S, 1 ,2 

qx 

a 

This  segment  should  not  be  placed  on  output  due  to  the 
process'  inability  to  read  this  segment  due  to  levels. 

\f 

w BAD_LEVEL 
Q 

set_acl  BAD_LEVEL  re  *.p5.* 

7.  Directory  for  SSA  tests 

Choose  a pathname  for  the  directory  S3A_TEST  as  illustrated  in  Fig 
ure  6.  The  subtree  must  be  created  by  the  SSA  logged  in  at  the  re 
quired  authorization.  The  following  script  is  an  example  of  the 
creation  of  this  subtree. 

login  SSA 

create_dir  SSA_TEST  -quota  3 -access_class  secret 

new_proc  -auth  secret 

change_wdir  SSA_TEST 

create  SEG 

create_dir  DIR 

reclassify_dir  DIR  "top  secret" 
set_system_priv  soos 
reclassify_dir  DIR  secret 
mbx  create  MS  EG 


logout 


r 


The  sequence  of  steps  above  creates  the  upgraded  directory  SSA_TEST 
at  the  access  class  secret,  and  the  contained  segment,  message  seg- 
ment, and  out  of  service  directory.  Since  there  is  no  direct  way  to 
set  the  out  of  service  bit,  the  out  of  service  bit  is  set  by  upgrad- 
ing the  directory  without  quota,  and  then  downgrading  it  again.  The 
system  privilege  "soos"  must  be  used  to  reclassify  an  out  of  service 
directory . 


I/O  DEVICES 

There  are  five  devices  required  for  the  I/O  tests:  a card  reader, 
a card  punch,  two  line  printers  with  accountability  terminals,  and  a 
magnetic  tape  input/output  device.  The  devices  used  in  the  I/O  tests 
must  have  specific  values  of  the  minimum  access  class,  maximum  access 
class,  and  minimum  banner  parameters.  Since  these  values  are  not 
likely  to  be  the  same  values  normally  used  by  the  installation,  spe- 
cial device  types  should  be  created  in  the  I/O  daemon  parrns  file  that 
contain  the  proper  values  of  the  parameters.  Then,  before  performing 
< a test  of  a particular  device,  the  proper  I/O  driver  can  be  logged  in 

with  the  proper  device  type  specified.  The  following  table,  repro- 
duced from  Section  III,  shows  the  values  of  these  parameters. 


device 

name 

min  class 

max  class 

min  banner 

card 

reader 

crd 

(none) 

S,c1  ,c2 

(none) 

card 

reader 

crd 

(none) 

U 

(none) 

card 

punch 

punch 

C,c1 ,c2 

S,c1 ,c2,c3,c4 

R,c  1 ,c2,c3 

line 

printer 

prt  1 

C,c1 ,c2 

S,c1 ,c2,c3,c4 

R,c  1 ,c2,c3 

line 

printer 

prt2 

S,c 1 ,c2,c3, 

,c4  T,c1 ,c2,c3,c4,c5 

T,c  1 ,c2,c3,c4 

tape 

drive 

tape 

C ,c 1 ,c2 

C,c  1 ,c2 

(none) 

J 
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APPENDIX  II 
TEST  SCRIPTS 


This  appendix  contains  the  scripts  for  the  tests  discussed  in 
Section  III,  For  the  test  sequences  consisting  entirely  of  scripts, 
the  complete  test  scripts  are  shown.  For  the  test  sequences  that  are 
composed  mostly  of  programs,  the  script  shows  the  login  and  the  call 
to  the  program  performing  the  test.  In  cases  where  a program  performs 
more  than  one  test,  a range  of  test  numbers  (e.g.  "SSC-3  to  SSC-10" ) 
is  indicated  for  a given  command  line. 

The  scripts  are  examples  of  what  the  printout  at  a terminal  might 
look  like  for  each  test.  They  are  not  to  be  taken  literally  in  all 
cases.  In  particular  the  names  of  users,  classifications,  and  con- 
tents of  certain  messages  are  shown  only  as  examples.  Lines  totally 
or  partially  containing  input  typed  by  the  user  are  preceded  by  an  as- 
terisk (*).  Lines  in  parentheses  are  comments  or  instructions.  All 
other  lines  are  produced  by  the  computer.  An  indented  line  may  be 
considered  a continuation  of  the  previous  line.  Each  test  beginning 
with  a test  number  can  be  run  independently  of  the  others,  except  when 
CONTINUE  appears  as  the  first  line  of  a script.  The  tests  marked 
CONTINUE  are  dependent  on  the  preceding  test  and  therefore  must  be 
run  immediately  following. 


Command  lines  that  contain  calls  to  commands  or  active  functions 
provided  as  part  of  the  test  package  are  indicated  in  the  scripts  by 
the  symbol  ">"  in  the  left  margin.  Explicit  usage  of  these  commands 
is  documented  in  Appendix  III,  and  the  source  listings  of  many  of 
these  appear  in  Appendix  IV  in  alphabetical  order.  All  other  commands 
are  standard  Multics  commands  documented  in  the  Multics  Programmers' 
Manual  [ 10 ] . 
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PASSWORD  DISTRIBUTION  (PDS) 


The  scripts  of  the  password  distribution  tests  described  in  Sec- 
tion III  (beginning  at  page  34)  are  presented  below.  The  scripts  are 
numbered  PDS-1  through  PDS-7,  corresponding  to  the  test  numbers  in  t,he 
text  of  Section  III.  The  project  referenced  in  these  tests  is  set  up 
in  the  test  environment  discussed  on  page  26  and  detailed  in  Appendix  I. 

PDS-1:  (SA  logs  in  and  initializes  password  of  ul  to  "passl".) 

(from  terminal  tl) 

Multics  1.1.1:  AF  Data  Services  Center. 

Load  = 27.0  out  of  50.0  units:  users  = 27 
•login  ul 
Password: 

•xxxxx  (This  should  be  ul's  old  password.) 

Login  incorrect. 

Please  try  again  or  type  "help"  for  instructions. 

PDS-2 : (CONTINUE) 

(User  puts  terminal  back  online) 

Multics  1.1.1:  AF  Data  Services  Center. 

Load  = 27.0  out  of  50.0  units:  users  = 27 
•login  ul-change_password 
Password : 

•passl 

New  password: 

•arptoa 

Password  changed. 

Your  password  has  been  given  incorrectly  once  since  last  correct  use. 
You  are  protected  from  preemption. 

ul  pi  logged  in  01/01/75  1200.0  edt  Mon  from  ASCII  terminal  "102". 

Last  login  01/01/75  1100.0  edt  Fri  from  ASCII  terminal  "101". 

r 1201  3-271  1.010  35 

•create  mailbox 

r 1201  1.023  .023  12 
•list 

Segments  = 1,  Records  = 0. 
r w 0 mailbox 
r 1202  .034  .120  15 
•logout 

ul  pi  logged  out  01/01/75  1203-2  edt  Mon 

CPU  usage  13  sec,  memory  usage  13.5  units. 
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PASSWORD  DISTRIBUTION  (PDS) 


(continued) 


PDS- 3 


PDS- 4 


J 


hangup 

(CONTINUE) 

(User  puts  terminal  online) 

Multics  1.1.1:  AF  Data  Services  Center. 

Load  = 27.0  out  of  50.0  units:  users  = 27 
•login  ul 
Password: 

•passl 

Login  incorrect. 

Please  try  again  or  type  "help"  for  instructions. 

•login  ul 
Password: 

•arptoa 

You  are  protected  from  preemption. 

Your  password  has  been  given  incorrectly  once  since  last  correct  use. 
ul  pi  logged  in  01/01/75  1213.4  edt  Mon  from  ASCII  terminal  "102". 

Last  login  01/01/75  1200.0  edt  Mon  from  ASCII  terminal  "102". 

r 1213  3-125  12.023  152 

•logout 

ul  pi  logged  out  01/01/75  1215.5  edt  Mon 

CPU  usage  7 sec,  memory  usage  152.4  units, 
hangup 

(CONTINUE) 

(user  puts  terminal  online) 

•login  ul  -generate_password 
Password: 

•arptoa 

Your  new  password  is  "bakops" , pronounced  "ba-kops". 

•Please  type  the  password:  nibno 
Password  changed . 

You  are  protected  from  preemption. 

ul  pi  logged  in  01/01/75  1215.7  edt  from  ASCII  terminal  "102". 

Last  login  01/01/75  1213.4  edt  Mon  from  ASCII  terminal  "102". 

r 1217  3-253  15.434  122 

•listacl  mailbox 

r w ul  .pi  .* 
rew  • .SysDaemon. • 


d2 


r 1217  .201  1.023  12 


(continued ) 


PASSWORD  DISTRIBUTION  (PDS) 


•logout 

ul  pi  logged  out  01/01/75  1219.2  edt  Mon 

CPU  usage  7 sec,  memory  usage  123.8  units, 
hangup 

PDS-5:  (CONTINUE) 

(user  puts  terminal  online) 

Multics  1.1.1:  AF  Data  Services  Center. 

Load  = 25  out  of  50.0  units:  users  = 25 
•login  ul 
Password: 

•bakops 

Login  incorrect. 

Please  try  again  or  type  "help"  for  instructions. 

•login  ul 
Password: 

•nibno 

Your  password  has  been  given  incorrectly  once  since  last  correct  use. 
You  are  protected  from  preemption. 

ul  pi  logged  in  01/01/75  1222.4  edt  Mon  from  ASCII  terminal  "102". 

Last  login  01/01/75  1219.2  edt  Mon  from  ASCII  terminal  "102". 

r 1220  3-333  14.234  199 

•logout 

ul  pi  logged  out  01/01/75  1221.2  edt  Mon 

CPU  usage  4 sec,  memory  usage  15.3  units, 
hangup 

PDS-6:  (user  puts  terminal  online) 

Multics  1.1.1:  AF  Data  Services  Center. 

Load  = 27.0  out  of  50.0  units:  users  = 27 
•login  u2  -generate_password 
Password: 

•xxxxxx  (This  should  be  u2's  current  password) 

Your  new  password  is  "rofine",  pronounced  "ro-fine". 

•Please  type  the  password:  xxxxxx  (Same  password  as  above) 

Incorrect . 

Your  new  password  is  "grece",  pronounced  "grece". 

•Please  type  the  new  password:  grece 
Password  changed. 

You  are  protected  from  preemption. 

u2  pi  logged  in  01/01/75  1230.2  edt  Mon  from  ASCII  terminal  "102". 

Last  login  01/01/75  1222.4  edt  Mon  from  ASCII  terminal  "102". 

r 1231  3-222  4.542  12 
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♦logout 

u2  pi  logged  out  01/01/75  1232.0  edt  Mon 

CPU  usage  4 sec,  memory  usage  14.2  units, 
hangup 

PDS-7 : (CONTINUE) 

(user  puts  terminal  online) 

Multics  1.1.1:  AF  Data  Services  Center. 

Load  = 27.0  out  of  50.0  units:  users  = 27 
♦login  u2  -change_password 
Password : 

♦grece 

Login  incorrect. 

You  must  use  the  -generate_password  option  to  change  your  password. 
Please  try  again  or  type  "help"  for  instructions. 

(user  hangs  up) 

(The  last  password  assigned  to  u2  in  PDS-6  (and  used  in  PDS-7) 
should  be  remembered  for  subsequent  logins.  Alternatively, 
the  SA  can  login  at  this  point  and  change  the  password  of  u2 
back  to  what  it  was  originally.) 


PROCESS  AUTHORIZATION  ASSIGNMENT  (PAA) 

The  scripts  of  the  process  authorization  tests  described  in  Sec- 
tion III  (beginning  at  page  38)  are  presented  below.  The  scripts  are 
numbered  PAA-1  through  PAA-34,  corresponding  to  the  test  numbers  in 
the  text  of  Section  III.  The  users  and  projects  referred  to  in  these 
scripts  are  those  set  up  in  the  test  environment  discussed  in  Section 
III  (on  page  26)  and  detailed  in  Appendix  I. 

For  conciseness,  the  -brief  option  is  always  specified  in  the 
login  line  and  on  logouts.  It  is  not  necessary  to  specify  this  option 
when  actually  running  the  tests,  although  it  is  recommended  that  the 
option  be  used  at  least  once  on  a legal  login  to  check  that  the  print- 
ing of  the  process  authorization  is  not  suppressed.  Ready  message  and 
password  input  have  been  omitted  from  the  scripts. 


PAA-1:  (from  terminal  tl) 

•login  ul  pi  -auth  secret 
Password: 

You  cannot  login  at  the  requested  authorization. 
Please  try  again  or  type  "help"  for  instructions. 

PAA-2:  (from  terminal  tl) 

•login  u3  pi  -auth  confidential 
Password: 

You  cannot  login  at  the  requested  authorization. 
Please  try  again  or  type  "help"  for  instructions. 

PAA-3:  (from  terminal  tl) 

•login  u2  pi  -auth  secret 
Password: 

You  cannot  login  at  the  requested  authorization. 
Please  try  again  or  type  "help"  for  instructions. 

PAA-4:  (from  terminal  t2) 

•login  ul  pi 
Password : 

Login  incorrect. 

Please  try  again  or  type  "help"  for  instructions. 
(Computer  operator  is  notified  of  illegal  login.) 

PAA-5:  (from  terminal  t2) 

•login  u2  pi  -auth  top_secret 
Password: 

You  cannot  login  at  the  requested  authorization. 
Please  try  again  or  type  "help"  for  instructions. 
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PROCESS  AUTHORIZATION  ASSIGNMENT  (PAA) 


(continued ) 


PAA-6 


PA  A- 7 


PA  A- 8 


PAA-9 


PAA- 1 


: (from  terminal  tl) 

•login  ul  pi  -auth  confidential  -brief 
Password : 

Your  authorization  is  confidential . 

> *authorization_tester 

Process  authorization  is:  confidential, 
•logout  -brief 

: (from  terminal  tl) 

•login  u2  pi  -auth  confidential  -brief 
Password: 

«*•••« 

Your  authorization  is  confidential . 


> *authorization_tester 

Process  authorization  is:  confidential, 
•logout  -brief 

: (from  terminal  tl) 

•login  u3  pi  -auth  unclassified  -brief 

Password: 

> *authorization_tester 

Process  authorization  is:  confidential, 
•logout  -brief 

: (from  terminal  t2) 

•login  u2  pi  -auth  secret  -brief 

«••••* 

Your  authorization  is  secret. 

*«»*»• 

> *authorization_tester 

Process  authorization  is:  secret, 
•logout  -brief 

0:  (from  terminal  tl) 

•login  u2  pi  -auth  confidential  -brief 

Password: 

*••••« 

Your  authorization  is  confidential. 


> *authorization_tester 

Process  authorization  is:  confidential, 
•logout  -brief 
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(continued ) 


PROCESS  AUTHORIZATION  ASSIGNMENT  (PAA) 


PA A— 11:  (from  terminal  t2) 

•login  ul  pi  -brief 
Password: 

> *authorization_tester 

Process  authorization  is: 
•logout  -brief 


unclassified . 


PAA- 1 2 


: (from  terminal  t2) 

•login  u2  pi  -auth  confidential  -change_default_auth  -brief 
Password: 

Default  authorization  changed. 

Your  authorization  is  confidential. 

«««««* 

•logout  -brief  -hold 
•login  u2  pi  -brief 
Password: 

****** 

Your  authorization  is  confidential. 

•**««« 

•authorization^  ester 
Process  authorization  is:  confidential. 

•logout  -brief 


PAA— 13:  (from  terminal  t2) 

•login  u2  p2  -auth  secret 

Password: 

You  cannot  login  at  the  requested  authorization. 

Please  try  again  or  type  "help"  for  instructions. 

PAA-14:  (from  terminal  t2) 

•login  u2  p2  -auth  confidential  -brief 

Password: 

«««*»* 

Your  authorization  is  confidential. 

««*•«* 

> *authorization_tester 

Process  authorization  is:  confidential. 

•logout  -brief 

PAA-15:  (from  terminal  t2) 

•login  u2  pi  -auth  secret 

Password : 

****** 

Your  authorization  is  secret. 
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PROCESS  AUTHORIZATION  ASSIGNMENT  (PAA) 

*abnormal_term  (terminates  process  abnormally) 

Fatal  error.  Process  has  terminated. 

New  process  created. 


Your  authorization  is  secret. 


> *authorization_tester 

Process  authorization  is:  secret. 


PAA-16:  (CONTINUE) 

*new_proc  -auth  confidential 


Your  authorization  is  confidential. 

> *authorization_tester 

Process  authorization  is:  confidential. 


PAA-17:  (CONTINUE) 

*new_proc  -auth  secret 

•«•#*« 

Your  authorization  is  secret. 

;•  *authorization_tester 

Process  authorization  is:  secret. 


PAA-18:  (CONTINUE) 

> *new_proc_test  -auth  top_secret 

You  cannot  new_proc  to  the  requested  authorization 

Your  authorization  is  secret. 

»*#«•» 

•logout  -brief 

PAA-19’*  (from  terminal  t3) 

•login  u4  p3  -auth  confidential , cl ,c2,c6,c7 
Password : 

You  cannot  login  at  the  requested  authorization. 
Please  try  again  or  type  "help"  for  instructions. 

PAA -20:  (from  terminal  t3) 

•login  u4  p3  -auth  confidential, cl ,c3,c6,c7 
Password : 

You  cannot  login  at  the  requested  authorization. 
Please  try  again  or  type  "help"  for  instructions. 


(continued ) 
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(continued ) 


PROCESS  AUTHORIZATION  ASSIGNMENT  (PAA) 


PAA-21:  (from  terminal  t3) 

•login  u4  p3  -auth  confidential ,c1 ,c4,c6,c7 

Password : 

You  cannot  login  at  the  requested  authorization. 

Please  try  again  or  type  "help"  for  instructions. 

PAA -22:  (from  terminal  t3) 

•login  u4  p3  -auth  confidential, cl ,c5,c6,c7 

Password : 

You  cannot  login  at  the  requested  authorization. 

Please  try  again  or  type  "help"  for  instructions. 

PAA-23:  (from  terminal  t3) 

•login  u4  p3  -auth  confidential , cl ,c6,c7  -brief 

Password: 

tHHI 

Your  authorization  is  confidential,  cl,  c6,  c7. 

i > *authorization_tester 

Process  authorization  is  secret, cl ,c6,c7. 

•logout  -brief 

TAA-24:  (from  terminal  t3) 

•login  u4  p3  -auth  confidential ,c 1 ,c6  -brief 

Password: 

*«•««« 

Your  authorization  is  confidential,  cl,  c6. 


> *authorization_tester 

Process  authorization  is:  confidential ,c 1 ,c6 . 

•logout  -brief 

PAA-25:  (from  terminal  1 3 ) 

•login  u4  p3 
Password: 

> *authorization_tester 

Process  authorization  is:  unclassified. 

•logout  -brief 

PAA-26:  (from  terminal  t3) 

•login  u5  p3  -auth  unclassified  -change_default_auth  -brief 
Password: 

Default  authorization  changed. 

•logout  -hold  -brief 

•login  u5  p3  -auth  confidential ,c6 ,c7  -change_default_auth  -brief 
Password: 


PROCESS  AUTHORIZATION  ASSIGNMENT  (PAA) 


(continued ) 


Default  authorization  changed. 

»«•••* 

Your  authorization  is  confidential,  c6,  c7. 

•logout  -brief  -hold 
•login  u5  p3  -brief 

Password: 

Your  authorization  is  confidential,  c6,  c7. 

*•««»« 

> •authorization_tester 

Process  authorization  is:  confidential ,c6,c7 . 
•logout  -brief 

PAA-27:  (from  terminal  t3) 

•login  u4  p4  -auth  confidential ,c4,c5,c6,c7 

Password : 

You  cannot  login  at  the  requested  authorization. 

Please  try  again  or  type  "help"  for  instructions. 

PAA-28:  (from  terminal  t3) 

•login  u4  p4  -auth  confidential, c4,c5,c6 

Password : 

Your  authorization  is  confidential,  c4,  c5,  c6. 

«**«*« 

> *authorization_tester 

Process  authorization  is:  confidential ,c4 ,c5 ,c6 . 
•logout  -brief 

PAA-29:  (from  terminal  t4) 

•login  u4  p3 

Password: 

Login  incorrect. 

Please  try  again  or  type  "help"  for  instructions. 

(Computer  operator  is  notified  of  illegal  login.) 

PAA-30:  (from  terminal  t3) 

•login  u4  p3  -auth  confidential , cl ,c6,c7  -brief 

Password: 

»••••» 

Your  authorization  is  confidential,  cl,  c6,  c7. 


•abnormal_term  (terminates  process  abnormally) 

Fatal  error.  Process  has  terminated. 

New  process  created. 


1 


(concluded)  PROCESS  AUTHORIZATION  ASSIGNMENT  (PAA) 


Your  authorization  is  confidential,  cl,  c6,  c7. 

> •authorization_tester 

Process  authorization  is:  confidential, cl ,c6,c7. 

PAA—  3 1 : (CONTINUE) 

*new_proc  -auth  confidential, cl ,c6 


Your  authorization  is  confidential,  cl,  c6,  c7. 

****** 

> *authorization_tester 

Process  authorization  is:  confidential. 

PAA-32:  (CONTINUE) 

*new_proc  -auth  confidential ,c  1 ,c7 

****** 

Your  authorization  is  confidential,  cl,  c7. 

> *authorization_tester 

Process  authorization  is:  confidential ,c 1 ,c7 . 

PAA-33:  (CONTINUE) 

> *new_proc_test  -auth  confidential, cl ,c4 

You  cannot  new_proc  to  the  requested  authorization. 

*»•••• 

Your  authorization  is  confidential,  cl,  c7. 

***•«• 

> *authorization_tester 

Process  authorization  is:  confidential ,c 1 ,c7 
•logout 

PAA-34:  (from  terminal  t3) 

•login  u5  p4 
Password: 

Your  cannot  login  at  your  default  authorization. 
Please  try  again  or  type  "help"  for  instructions, 
(user  hangs  up) 


St£Gf1F  JT  ACL  CONTROLS  (SAC) 

The  segment  ACL  controls  tests  described  beginning  on  page  45  are 
performed  by  a single  command  executed  by  the  user  while  at  some  fixed 
authorization,  either  system_low  or  otherwise.  The  tests  must  be  per- 
formed by  two  processes  having  different  process  identifiers.  This 
means  that  the  two  processes  must  have  different  user  names  and/or 
different  project  names.  The  authorizations  of  the  users  are  unimpor- 
tant --  unclassified  can  be  used.  Although  any  user  names  and  pro- 
jects may  be  used,  the  users  ul  and  u2  and  projects  pi  and  p2  are  used 
below  as  examples. 

SAC-1  to  SAC-25: 

ul : ‘login  ul  pi 

Password: 

> ‘test  seg  acl 

“*  Login  at  second  terminal,  under  a different  name  and/or  project. 

*“  Issue  the  command:  "test  seg  acl  ul  pi" 

u2:  ‘login  u2  p2 

Password: 

> »test_seg  acl  ul  pi 

“*  Ret  to  first  terminal,  type  an  s. 

ul:  »s 

r 959  4.440  56.069  493 

u2 : r 575  4.233  43-233  123 

‘logout 

ul : ‘logout 

, ppearance  of  a ready  message  on  both  terminals  indicates  proper 
completion  of  the  test  with  no  errors.  The  correspondence  between  the 
test  numbers  and  the  code  that  implements  the  test  can  be  found  in  the 
listings  of  test  seg  acl.pl  1 and  supporting  routines  in  Appendix  IV. 
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SEGMENT  SECURITY  CONTROLS  (SSC) 

The  segment  security  controls  tests  discussed  on  page  52  are  per- 
formed by  executing  a single  command  from  a process  logged  in  at  an 
authorization  equal  to  the  third  argument  in  the  call  to 
create_test_seg.ec  during  test  initialization  as  shown  at  the  middle 
of  page  86.  Any  user  with  the  ability  to  login  at  that  authorization 
may  be  used.  In  this  script,  user  u7  on  project  p5  is  used,  with  au- 
thorization secret, c1,c2  as  in  the  examples.  The  directory  SEG_TEST, 
created  during  initialization,  is  referenced  in  the  script  as  the  ar- 
gument to  the  test  seg  auth  command. 

SSC-1  to  SSC- 12: 

•login  u7  p5  -auth  secret, cl, c2 
Password : 

Your  authorization  is  secret,  cl,  c2. 

»***•* 

r 1230  4.344  23.544  576 

> *test  seg  auth  SEG_TEST 
r 1231  0.608  3.234  455 

•logout 

The  ready  message  indicates  proper  termination  of  the  test  with 
no  errors  detected.  The  correspondence  between  the  test  number  and 
the  actual  code  that  performs  the  test  can  be  found  in  the  listing  of 
test_dir_auth.pl 1 in  Appendix  IV. 
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DIRECTORY  SECURITY  CONTROLS  (DSC) 

The  directory  security  controls,  discussed  on  page  54,  are  tested 
by  a script  very  similar  to  that  for  the  segment  security  controls 
(SSC).  That  same  discussion  applies  to  the  script  below. 

DSC- 1 to  DSC- 1 7 : 

•login  u7  p5  -auth  secret, cl, c2 
Password : 

Your  authorization  is  secret,  cl,  c2. 

«**••• 

r 1230  4.444  2.343  122 

> *test_dir_auth  DIR_TEST 
r 1231  15.222  4.328  154 

•logout 

Again,  the  ready  message  indicates  completion  of  the  test  with  no 
errors.  The  correspondence  between  the  individual  test  numbers  and 
the  code  that  performs  the  test  can  be  found  in  the  listing  of 
test_dir_auth.pl  1 in  Appendix  IV. 

Failure  of  the  test_dir_auth  command  as  indicated  by  an  error 
message  may  simply  be  due  to  a system  change  that  returns  a slightly 
different  status  code  in  some  call  to  an  hcs_  entry  point.  The 
test_dir_auth  command  usually  terminates  the  test  when  any  error  is 
encountered.  In  order  to  determine  all  the  status  codes  that  have 
been  changed,  the  user  may  call  check_status_$return  before  the 
test_dir_auth  command.  See  the  writeup  of  check_status_  for  a de- 
tailed explanation  of  the  operation  involved. 
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INTERPROCESS  COMMUNICATION  (IPC) 


r 


I 


I 


The  IPC  tests  discussed  on  page  57  are  performed  by  two  proc- 
esses, which  may  or  may  not  be  originated  by  the  same  user.  In  the 
example  in  the  script  below,  users  u6  and  u7  on  project  p5  are  used. 

It  is  assumed  that  user  u6  has  the  call  to  test_ipc  in  his  start_up.ec 
as  described  in  initialization  on  page  85. 

IPC-1  to  I PC-6: 

u6:  “login  u6  p5 
Password : 

r 1202  5-1^3  35.221  456 

> »test_ipc  C, 1 ,2  S, 1 S , 1 , 2 S, 1,2,3  T,1,2  S, 1 , 3 

»**  Login  at  second  terminal  with  authorization  = S,1,2 
Issue  the  command  "test_ipc". 

u7:  “login  u7  p5  -auth  S,1,2 
Password: 

«**»•» 

Your  authorization  is  secret,  cl,  c2. 
r 1205  5.133  35.344  567 

> *test_ipc 

***  You  will  need  the  following  three  numbers,  back  at  the 
first  terminal. 

1. )  012345673^16 

2. )  750364263444 

3. )  463764263035 

**»  Return  to  first  terminal,  type  the  character  s. 
u6 : *s 

***  Using  the  output  from  other  terminal,  answer  the  following. 

* First  number  = 012345673416 

“ Second  number  = 750364263444 

• Third  number  = 463764263035 


Your  authorization  is  confidential,  cl,  c2. 


L 


INTERPROCESS  COMMUNICATION  (IPC) 


(concluded) 


i 


J 

I 

H 

i 


Your  authorization  is  secret,  cl. 


Your  authorization  is  secret,  cl,  c 2. 

****** 

*»*»*• 

Your  authorization  is  secret,  cl,  c2,  c3. 

*#*»*» 


Your  authorization  is  top  secret,  cl,  c2. 

»*#••« 


Your  authorization  is  secret,  cl,  c3. 

r 1206  5.322  34.450  568 

u7:  r 1206  2.343  34.232  456 
•logout 

u6:  *logout 

The  source  code  that  implements  the  individual  tests 
in  the  listing  of  test_ipc.pl1  and  supporting  routines  in 


106 


MESSAGE  SEGMENTS  (MBX) 


The  message  segment  tests  discussed  on  page  60  are  performed  by  a 
single  user.  Any  user  on  any  terminal  able  to  login  to  at  least  three 
levels  and  three  categories  may  be  used.  For  these  scripts,  user  u7 
on  project  p5  is  used. 

MBX- 1 to  MBX-6 : 

•login  u7  p5 
Password : 

> *exec_com  mbx_test  C,1,2  T,1,2  S , 1 , 2 S, 1 S,1,2,3  S,1,3 

•Do  you  want  to  delete  your  old  mailbox?  Yes. 

Please  ignore  tne  next  six  "Input:"  lines. 


Your  authorization  is  secret,  cl,  c2. 

**•**« 


Input : 

««•••« 


Your  authorization  is  confidential,  cl,  c2. 

**»*»* 


Input : 

IHtll 

Your  authorization  is  secret,  cl. 


Input : 

»*•••« 

Your  authorization  is  top  secret,  cl,  c2. 

ilttll 

Input: 


Your  authorization  is  secret,  cl,  c2,  c3. 


Input : 

>»»•>« 

Your  authorization  is  secret,  cl,  c3. 


Input : 

«»*»»• 


Your  authorization  is  secret,  cl,  c2. 


mbx_test:  Messages  A,  B,  and  C should  follow,  plus  "Incorrect 
access"  messages  from  mail  regarding  2 and  3: 
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MESSAGE  SEGMENTS  (MBX)  (concluded) 

3 messages. 

1)  From:  u7.p5  01/01/75  1200.0  edt  Mon  (1  line) 

A.  This  message  is  S,1,2. 

2)  From:  u7.p5  01/01/75  1200.5  edt  tlon  (1  line) 

B.  This  message  is  C,1,2. 

3)  From:  u7.p5  01/01/75  1200.9  edt  Mon  (1  line) 

C.  This  message  is  S,1. 

mail:  Incorrect  access  on  entry.  Message  2 not  deleted, 
mail:  Incorrect  access  on  entry.  Message  3 not  deleted. 

mbx_test:  Messages  B and  C should  now  follow: 

2 messages. 

1)  From:  u7.p5  01/01/75  1200.5  edt  Mon  (1  line) 

B.  This  message  is  C,1,2. 

2)  From:  u7.p5  01/01/75  1200.9  edt  Mon  (1  line) 

C.  This  message  is  S,1. 

mbx_test:  One  final  error  message  from  mbx_delete: 

mbx_delete:  Incorrect  access  to  directory  containing  entry. 
>udd>p5>u7>u7.mbx 

»mbx_test:  Everything  as  expected?  yes 
r 1210  3-456  12.324  456 

•logout 

The  commands  that  implement  the  tests  can  be  found  in  the  listing 
of  aim_test_exec_coms  in  Appendix  IV.  There  is  no  direct  correspond- 
ence between  test  number  and  lines  of  code,  however,  because  the  test 
numbers  merely  refer  to  the  individual  messages  that  are  sent  or  the 
various  authorizations.  See  the  writeup  of  mbx_test.ec  in  Appendix 
III  for  a description  of  the  six  arguments  to  mbx_test. 
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CARD  INPUT  ( CIF ) 


The  scripts  of  the  card  deck  input  tests  described  in  Section  III 
(beginning  on  page  62)  are  presented  below.  The  scripts  are  numbered 
CIF-1  through  CIF-24,  corresponding  to  the  test  numbers  in  the  text  of 
Section  III.  The  user  and  projects  referred  to  in  these  scripts  are 
those  set  up  in  the  test  environment  discussed  in  Section  III  (on  page 
26)  and  detailed  in  Appendix  I. 

For  each  of  the  tests  CIF-1  to  CIF-1 4 the  card  reader  is  to  be 
logged  in  at  the  indicated  authorization.  These  authorizations  have 
been  set  up  at  initialization  as  shown  in  the  table  on  page  89.  The 
first  14  tests  consist  of  reading  cards  into  the  card  reader  as  indi- 
cated, where  each  line  in  the  script  represents  one  card.  The  symbols 
<UID>  and  <EOF>  represent  a unique  id  and  end  of  file  card  respective- 
ly. The  result,  where  shown,  indicates  whether  the  cards  were  accept- 
ed or  rejected.  A reject  does  not  necessarily  mean  that  the  card 
reader  refuses  to  read  to  the  end  of  the  deck.  However,  the  operator 
should  be  notified  of  the  error. 

Although  the  first  14  tests  are  independent,  it  is  not  neces- 
sary to  login  the  card  reader  for  each  test  if  the  card  reader  did  not 
log  itself  out  after  the  previous  test.  The  only  requirement  is  that 
the  authorization  of  the  card  reader  is  as  specified. 

CIF-1:  (login  card  reader  at  secret .c 1 ,c2) 

cards:  <UID> 

U7.P5  SECRET, Cl ,C2; 

CIF-1  MCC 

"THIS  IS  TEST  DATA  FOR  TEST  CIF-1" 

<EOF> 

<UID> 

result:  accepted 

CIF-2:  (login  card  reader  at  secret ,c 1 ,c2) 

cards:  <UID> 

U6.P5  UNCLASSIFIED, Cl , C2 ; 

CIF-2  MCC 

"THIS  IS  TEST  DATA  FOR  TEST  CIF-2" 

<EOF> 

<UID> 

result:  rejected 
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CARD  INPUT  ( CIF ) 


(continued ) 


CIF-3:  (login  card  reader  at  secret, cl ,c2) 

cards:  <UID> 

U6.P5  SECRET, Cl ; 

CIF-3  MCC 

"THIS  IS  TEST  DATA  FOR  TEST  CIF-3" 

<EOF> 

<UID> 

result:  rejected 

CIF-4:  (login  card  reader  at  secret, c 1 ,c2) 

cards:  <UID> 

U6.P5  SECRET, Cl ,C2,C3; 

CIF-4  MCC 

"THIS  IS  TEST  DATA  FOR  TEST  CIF-4" 

<EOF> 

<UID> 

result:  rejected 

CIF-5:  (login  card  reader  at  secret ,c 1 ,c2) 

cards:  <UID> 

U6.P5  TOP  SECRET, Cl ,C2; 

CIF-5  MCC 

"THIS  IS  TEST  DATA  FOR  TEST  CIF-5" 

<EOF> 

<UID> 

result:  rejected 

CIF-6:  (login  card  reader  at  secret, cl ,c2) 

cards:  <UID> 

U6.P5  SECRET, C3; 

CIF-6  MCC 

"THIS  IS  TEST  DATA  FOR  TEST  CIF-6" 

<EOF> 

<UID> 

result:  rejected 

CIF-7:  (login  card  reader  at  secret , cl ,c2) 

cards:  <UID1> 

U6.P5  SECRET, Cl ,C2; 

CIF-7  MCC 

"THIS  IS  TEST  DATA  FOR  TEST  CIF-7" 

<EOF> 

<UID2>  (this  UID  card  is  to  be  different  from  <UID1>  above) 
result:  rejected 


(continued ) 


CARD  INPUT  ( CIF ) 


CIF-8:  (login  card  reader  at  secret, cl ,c2) 

cards:  <UID> 

U7.P5  SECRET, 

Cl ,C2 ; 

CIF-8  mcc 

"THIS  IS  TEST  DATA  FOR  TEST  CIF-8" 
<E0F> 

<UID> 

result:  accepted 

CIF-9:  (login  card  reader  at  secret ,c 1 ,c2) 

cards:  <UID> 

U6.P5; 

CIF-9  MCC 

"THIS  IS  TEST  DATA  FOR  TEST  CIF-9" 
<EOF> 

<UID> 

result:  rejected 

CIF-10:  (login  card  reader  at  unclassified) 

cards:  <UID> 

U7.P5; 

CIF-10  MCC 

"THIS  IS  TEST  DATA  FOR  TEST  CIF-10" 
<EOF> 

<UID> 

result:  accepted 

CIF-11:  (login  card  reader  at  unclassified) 
cards:  <UID> 

U6.P5  UNSECRET; 

CIF- 1 1 MCC 

"THIS  IS  TEST  DATA  FOR  TEST  CIF-11" 
<EOF> 

<UID> 

result:  rejected 

CIF-12:  (login  card  reader  at  unclassified) 
cards:  <UID> 

* . P5 ; 

CIF-12  MCC 

"THIS  IS  TEST  DATA  FOR  TEST  CIF-12" 
<E0F> 

<UID> 

result:  rejected 
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CARD  INPUT  ( CIF ) (continued) 

CIF-13:  (login  card  reader  at  unclassified) 
cards:  <UID> 

U6.P5; 

CIF- 1 3 qqq 

"THIS  IS  TEST  DATA  FOR  TEST  CIF-13" 

<EOF> 

<UID> 

result:  rejected 

CIF-14:  (login  card  reader  at  unclassified) 
cards:  <UID> 

U7.P5  UNCLASSIFIED; 

CIF- 1 0 MCC 

"THIS  IS  TEST  DATA  FOR  TEST  CIF-14" 

<EOF> 

<UID> 

result:  accepted 

CIF-15:  (from  terminal  t5) 

•login  u7  p5  -auth  secret, cl, c2  -bf 
Password: 

«**•«* 

Your  authorization  is  secret, cl ,c2. 

r 1737  0.362  1.482  37 

*change_wdir  >ddd>cards 
r 1738  0.055  0.546  24 

•list  -a 

Segments  =0. 

Directories  = 2,  Records  s 2. 

s 1 system_low 

s 1 ! bBBBBBBBBBJBBB 

Multisegment-files  = 0. 

Links  = 0. 


r 1738  0.649  2.252  45 

(The  directory  named  (bBBBBBBBBBJBBB  corresponds  to  a 
secret, d,c2  directory.  It  is  the  value  returned  from  the  ac- 
tive function  [encode_authorization  secret, cl ,c2] . ) 


1 


CIF-17:  (CONTINUE) 

*change_wdir  u7 
r 1738  0.060  0.672  38 

*list  -a 

Segments  = 2 Records  = 2. 

r 1 cif-1 

r 1 cif-8 

Directories  = 0. 

Multisegment-files  = 0 

Links  = 0. 

r 1739  0.156  1 .700  31 
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CARD  INPUT  (CIF)  (continued) 

GIF- 1 3 : (CONTINUE) 

•print  cif-1 

cif-1  06/P  1/75  1752.3  edt  Sat 

"tnis  is  test  data  for  test  cif-1" 
r 1752  0.267  1.122  32 


CIF- 19 

4 

CIF-20 


CIF-21 


i J 


(CONTINUE) 

•list_acl  >ddd>cards 

sma  IO.SysDaemon. • 

sma  #.SysDaemon.* 

s *.«.* 

r 1759  0.160  4.686  82 


(CONTINUE) 

*list_acl  < 

sma  IO.SysDaemon.* 

sma  *.SysDaemon.* 

s *.».* 

r 1800  0.116  0.306  16 


(CONTINUE) 
•list  acl 


sma 

IO.SysDaemon 

s 

u7.».* 

sma 

•.SysDaemon. 

r 1801 

0.134  3 194  56 
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(con  inued)  CARD  INPUT  (CIF) 

CIF-  2:  ( CONTINUE) 

*list_acl  cif-1 

rw  10. SysDaemon.* 
r u7.p5.# 
rw  * .SysDaemon. * 

r 1302  0.391  6.714  94 

CIF-23:  (CONTINUE) 

*new_proc  -auth  unclassified 


Your  authorization  is  unclassified 
r 1 B02  0.924  8.930  88 
*copy_cards  cif-10 

copy_cards:  2 copies  of  cif-10  exist 

1 card  decks  copied 
r 1803  0.061  0.554  27 

CIF-24:  (CONTINUE) 

*list_acl  -pn  >system_library_1 >ioi_ 

re  10. SysDaemon. * 

re  •.SysDaemon.* 

r 1803  0.053  0.645  29 

OPERATOR:  (CLEANUP) 

delete_dir  >udd>cards>system_low>u7 

delete_dir  >udd>cards>[encode_authorization  secret, cl ,c2]>u7 
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OUTPUT  ( CPT ) 


CAP.. 

The  scriots  of  the  card  punch  described  in  Section  III  (beginning 
on  page  66)  are  presented  below.  The  scripts  are  numbered  CPT-1 
through  CPT-1 1 corresponding  to  the  test  numbers  in  the  text  of  Sec- 
tion III.  The  users  and  projects  referred  to  in  these  scripts  are 
those  set  up  in  the  test  environment  discussed  in  Section  III  and  de- 
tailed in  Appendix  1. 

Tne  puncn  must  be  initialized  to  the  access  class  and  other  pa- 
rameters specified  in  the  table  on  page  89  during  initialization.  It 
is  assumed  that  the  punch  is  turned  on  and  that  the  queue  is  initially 
empty.  Following  each  dpunch  command  the  I/O  coordinator  returns  in- 
formation regarding  the  number  of  requests  signalled  by  the  dpunch 
command  and  the  number  of  requests  already  queued  for  output.  These 
numb-  rs  should  be  checked  for  correctness. 

CPT-1:  (from  terminal  t5) 

•login  u7.p5  -auth  confidential , cl ,c2  -bf 

Password: 

*»*•*» 

Your  authorization  is  confidential, cl ,c2. 

***«•* 

r 1551  0.760  2.498  47 


•dpunch  -mcc  I0_TEST>0UTPUT 
1 request  signalled,  0 already  queued 
r 1553  0.719  12.098  149 


punci:  Segment  punched:  OUTPUT 
Banner:  H,c1,c2,c3 

CPT-2 : (CONTINUE) 

*new_proc  -auth  unclassified ,c 1 ,c2 


Your  authorization  is  unclassified, cl ,c2. 


r 1554  0.941  9.554  119 


•dpunch  -mcc  I0_TEST>N0_0UTPUT 
1 request  signalled,  0 already  queued 
r 1555  0.258  0.420  23 


punch:  No  output  punched. 

CPT-3 : (CONTINUE) 

*new_proc  -auth  confidential ,c 1 
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(continued) 


CARD  OUTPUT  (CPT) 


Your  authorization  is  confidential ,c 1 . 


r 1556  0.920  6.806  78 

•dpunch  -mcc  I0_TE3T>N0_0UTPUV' 

1 request  signalled,  0 already  queued 
r 1556  1.817  16.704  123 

punch:  No  output  punched. 

CPT-4 : (CONTINUE) 

*new_proc  -auth  confidential , cl ,c2,c3,c4,c5 

****** 

Your  authorization  is  confidential.cl ,c2,c3,c4,c5. 

*•••*• 

r 1557  0.920  6.806  73 

•dpunch  -mcc  I0_TEST>N0_0UTPUT 
1 request  signalled,  2 already  queued, 
r 1558  0.218  1 .332  33 

punch:  No  output  punched. 

CPT-5:  (CONTINUE) 

*new_proc  -auth  top_secret ,c 1 ,c2 


Your  authorization  is  top_secret,c 1 ,c2. 


r 1559  0.921  6.806  78 

•dpunch  -mcc  I0_TEST>N0_0UTPUT 
1 request  signalled,  2 already  queued 
r 1560  1.774  16.704  123 

punch:  No  output  produced. 

CPT-6:  (CONTINUE) 

*new_proc  -auth  confidential ,c2,c3 


Your  authorization  is  confidential ,c2,c3. 


r 1560  0.920  6.806  78 

•dpunch  -mcc  I0_TEST>N0_0UTPUT 
1 request  signalled,  0 already  queued. 


CARD  OUTPUT  (CPT)  (continued) 

r 1561  1.803  17.616  18 1 

punch:  No  output  produced 

CPT-7 : ( CONTINUE) 

•new _proc  -auth  confidential ,c  1 ,c2 

Your  authorization  is  confidential , cl ,c2. 

r 1562  0.921  7.482  81 

*change_wdir  I0_TE3T 
r 1563  0.060  0.672  12 

> *dpunch_test  -mcc  S, 1 ,2>BAD_LEVEL 

1 request  signalled,  2 already  queued, 
r 1563  1 .817  16.704  153 

punch:  Error  message  indicating  inability  to  access  S, 1 ,2>BAD_LEVEL 
CPT-3:  (CONTINUE) 

> *dpunch_test  -mcc  C, 1 ,2,3>BAD_CATEG0RY 

1 request  signalled,  2 already  queued, 
r 1564  1 .817  28.020  163 

punch:  Error  message  indicating  inability  to  access  C, 1 ,2,3>BAD_CATEG0RY 

CPT-9:  (CONTINUE) 

> *dpunch_test  -mcc  BAD_ACL 

1 request  signalled  2 already  queued, 
r 1564  0.233  2.678  54 

puncn:  Error  message  indicating  inability  to  access  BAD_ACL 

CPT-10:  (CONTINUE) 

•dpunch  -mcc  OUTPUT 
1 request  signalled  2 already  queued 
r 1565  1.830  17.616  181 

punch:  Banner:  R,c1,c2,c3 

Segment  punched:  OUTPUT 

CPT-11:  (CONTINUE) 

•new_proc  -auth  secret, cl ,c2,c3,c4 


Your  authorization  is  secret, cl ,c2,c3,c4. 
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(concluded)  CARD  OUTPUT  (CPT) 


r 1566  0.920  6.806  78 

•dpunch  -mcc  I0_TEST>0UTPUT 
1 request  signalled  3 already  queued, 
r 1567  0.86  3-948  56 

punch:  Banner:  S,c1 ,c2,c3,c4 

Segment  punched:  OUTPUT 

OPERATOR:  (CLEANUP) 

Delete  all  dpunch  requests  from  the  punch  queue. 


r 

I 


LINE  PRINTER  (LPT) 

The  scripts  for  the  line  printer  described  in  Section  III  (begin- 
ning on  page  68)  are  presented  below.  The  scripts  are  numbered  LPT-1 
through  LP1-22  corresponding  to  the  test  numbers  in  the  text  of  Sec- 
tion III.  The  users  and  projects  referred  to  in  these  scripts  are 
those  set  up  in  the  test  environment  discussed  in  Section  III  and  de- 
tailed in  Appendix  I. 

The  access  classes  for  the  two  printers  prtl  and  prt2,  and  other 
attributes,  are  specified  during  initialization  as  summarized  in  the 
table  on  page  89. 

Initially  prtl  should  be  logged  in,  but  not  prt2.  It  is  assumed 
that  the  dprint  queues  are  empty  at  the  start.  Following  each  dprint 
command  the  I/O  coordinator  returns  information  regarding  the  number 
of  requests  signalled  by  the  dprint  command  and  the  number  of  requests 
already  queued  for  output.  These  numbers  should  be  checked  for  cor- 
rectness. Tney  will  be  correct  only  if  the  printer  has  completed 
printing  the  results  of  the  previous  requests.  Thus,  the  user  should 
wait  for  the  printer  to  complete  any  output  from  the  previous  test  be- 
fore continuing  with  the  next  test. 

LPT-1:  (from  terminal  t5) 

•login  u7  p5  -auth  confidential , cl ,c2  -bf 
Password: 

••••** 

Your  authorization  is  confidential, cl ,c2. 

»«»*»• 

r 1551  0.760  2.498  47 

•dprint  I 0_TEST> OUTPUT 
1 request  signalled,  0 already  queued 
r 1553  0.719  12.098  149 

prtl:  Segment  printed:  OUTPUT 
Banner:  R,c1,c2,c3 

LPT-2:  (CONTINUE) 

*new_proc  -auth  unclassified ,c 1 ,c2 

•*•••• 

Your  authorization  is  unclassified ,c 1 ,c2 . 
r 1554  0.941  9.554  1 19 


| 
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(continued ) 


LINE  PRINTER  (LPT) 


•dprint  I0_TE8T>N0_0UTPUT 
1 request  signalled,  0 already  queued 
r 1555  0.258  0.420  23 

prt 1 : No  output  printed. 

LPT-3 : (CONTINUE) 

*new_proc  -auth  confidential , cl 

****** 

Your  authorization  is  confidential, cl . 

****** 

r 1556  0.920  6.806  ?8 

•dprint  I0_TEST>N0_0UTPUT 
1 request  signalled,  0 already  queued 
r 1556  1.817  16.704  123 

prtl:  No  output  printed. 

LPT-4 : (CONTINUE) 

*new_proc  -auth  conf ident ial , c 1 ,c2 ,c 3 , c4 ,c5 

****** 

Your  autnorization  is  confidential ,c 1 ,c2,c3 ,c4 ,c5 . 

****** 

r 1557  0.920  6.806  78 

•dprint  I0_TEST>N0_0UTPUT 
1 request  signalled,  2 already  queued, 
r 1558  0.218  1 .332  33 

prtl:  No  output  printed. 

LPT-5 : (CONTINUE) 

•new_proc  -auth  top_secret ,c 1 ,c2 

«*•*»» 

Your  authorization  is  top_secret,c1 ,c2. 

•*•*•» 

r 1559  0.921  6.806  78 

•dprint  I0_TEST>N0_0UTPUT 
1 request  signalled,  2 already  queued 
r 1560  1 .774  16.704  123 

prt  1 : 


No  output  produced. 


LINE  PRINTER  (LPT) 


(continued ) 


LPT-6 : (CONTINUE) 

*new_proc  -auth  confidential ,c2,c3 

Your  authorization  is  confidential ,c2,c3. 

****** 

r 1560  0.920  6.806  78 

•dprint  I0_TEST>N0_0UTPUT 
1 request  signalled,  0 already  queued, 
r 1561  1.803  17.616  1 8 1 

prtl:  No  output  produced 

LPT-7 : (CONTINUE) 

*new_proc  -auth  confidential , cl ,c2 

•*•••• 

Your  authorization  is  confidential , cl ,c2. 

****** 

r 1562  0.921  7.482  81 

*change_wdir  I0_TEST 
r 1563  0.060  0.672  12 

> *dprint_test  S, 1 ,2>BAD_LEVEL 

1 request  signalled,  2 already  queued, 
r 1563  1 .817  16.704  153 

prtl:  Error  message  indicating  inability  to  access  S, 1 ,2>BAD_LEVEL 

LPT- 8:  (CONTINUE) 

> *dprint_test  C , 1 , 2 , 3>BAD_CATEG0RY 

1 request  signalled,  2 already  queued, 
r 1564  1.817  28.020  163 

prtl:  Error  message  indicating  inability  to  access  C, 1 ,2,3>BAD_CATEG0RY 

LPT-9:  (CONTINUE) 

> *dprint_test  BAD_ACL 

1 request  signalled,  2 already  queued, 
r 1564  0.233  2.678  54 

prtl:  Error  message  indicating  inability  to  access  BAD_ACL 

LPT-10:  (CONTINUE) 

•dprint  OUTPUT 

1 request  si. nailed,  2 already  queued 


(continued) 


LINE  PRINTER  (LPT) 


r 1565  1 .830  17.616  181 

prtl:  Segment  printed:  OUTPUT 
Banner:  R,c1,c2,c3 

LPT- 11  & LPT-12:  (CONTINUE) 

*new_proc  -auth  secret, cl ,c2,c3,c4 

Your  authorization  is  secret, cl ,c2,c3,c4. 

•••**« 

r 1566  0.920  6.806  78 

*change_wdir  I0_TEST 
r 1566  0.060  0.672  12 

*dprint  OUTPUT 

1 request  signalled,  3 already  queued 
r 1615  0.922  5.512  78 

prtl:  Segment  printed:  OUTPUT 
Banner:  3, cl ,c2,c3,c4 
Top  page  label:  unclassified 
Bottom  page  label:  unclassified 

LPT- 13:  (CONTINUE)  j 

•dprint  -access_label  OUTPUT 
1 request  signalled,  3 already  queued 
r 1616  2.033  33.206  187 

J 

I 

prtl:  Segment  printed:  OUTPUT 

Top  page  label:  unclassified 
Bottom  page  label:  unclassified 

LPT- 1 4 : (CONTINUE) 

•dprint  -label  "This  is  confidential"  OUTPUT 
1 request  signalled,  3 already  queued, 
r 1626  0.435  13.116  109 

prtl:  Segment  printed:  OUTPUT 

Top  page  label:  This  is  confidential 
Bottom  page  label:  This  is  confidential 


LINE  PRINTER  (LPT) 


(continued ) 


LPT- 1 5 : (CONTINUE) 

•dprint  -top_label  "This  is  a top  label"  OUTPUT 
1 request  signalled,  3 already  queued, 
r 1632  0.243  4.314  71 

prt 1 : Segment  printed:  OUTPUT 

Top  page  label : This  is  a top  label 
Bottom  page  label:  unclassified 

LPT-1 6:  (CONTINUE) 

•dprint  -bottom_label  "This  is  a bottom  label"  OUTPUT 

1 request  signalled,  3 already  queued 
r 1637  0.251  4.673  68 

prt 1 : Segment  printed:  OUTPUT 

Top  page  label:  unclassified 

Bottom  page  label:  This  is  a bottom  label 

LPT-1 7:  (CONTINUE) 

(Operator  brings  up  printer  prt2) 

•dprint  LONG  LONG 

2 requests  signalled,  3 already  queued 
r 1638  1 .589  18.754  216 

prt 1 : Segment  printed:  LONG 
Banner:  S,c1,c2,c3 
prt2:  Segment  printed:  LONG 
Banner:  T,c1 ,c2,c3,c4 

LPT-18:  (CONTINUE) 

*new_proc  -auth  top_secret ,c 1 ,c2,c3,c4 

**«»»» 

Your  authorization  is  top  secret, cl ,c2,c3,c4. 

r 1639  0.930  9.120  92 

•dprint  I0_TEST>L0NG  I0_TEST>L0NG 
2 requests  signalled,  4 already  queued 
r 1640  0.938  3.102  80 

prtl:  No  output. 

prt2:  Segments  printed:  LONG  (2  copies) 

Banners:  TS,c1,c2,c3,c4 
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(concluded) 


LINE  PRINTER  (LPT) 


LPT- 19:  (CONTINUE) 

*new_proc  -auth  secret , cl ,c2,c3,c4,c5 

Your  authorization  is  secret, cl ,c2,c3,c4,c5. 

r 1640  0.941  9.554  1 19 

•dprint  IO_TEST>LONG  IO_TEST>LONG 
2 requests  signalled,  4 already  queued 
r 1641  2.177  22, 112  144 

prt 1 : No  output 

prt2:  Segments  printed:  LONG  (2  copies) 

3anners:  T,c1 ,c2,c3,c4,c5 

LPT-20 : (CONTINUE) 

(Operator  should  check  that  there  is  one  accountability  form 
for  each  of  the  tests  LPT-1,  and  LPT-7  through  LPT-19.  The 
information  appearing  on  the  accountability  form  should  be 
checked  for  correctness.) 

LPT-21:  (Operator  brings  up  prtl  but  not  the  accountability  terminal) 
•login  u7  p5  -auth  confidential, cl ,c2  -bf 
Password: 

****** 

Your  authorization  is  confidential , cl ,c2. 

****** 

r 1642  0.362  1.462  37 

*change_wdir  I0_TEST 
r 1643  0.065  0.546  24 

•dprint  LONG  LONG 

2 requests  signalled,  2 already  queued 
r 1643  0.921  8.190  86 

prtl:  No  output  is  produced  because  accountability  terminal  not 
dialed  up. 

LPT-22:  (CONTINUE) 

(Operator  dials  up  accountability  terminal  for  prtl) 

prtl:  Segment  LONG  begins  printing. 

(Operator  disconnects  accountability  terminal  for  prtl  while 
prtl  is  still  printing  first  copy  of  LONG.) 
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LINE  PRINTER  (LPT) 


(concluded) 


prtl : Second  copy  of  segment  LONG  not  printed. 

OPERATOR : (CLEANUP) 

Delete  all  dprint  requests  from  the  print  queue. 


TAPE  I/O  ( TDT) 


The  tests  for  tape  I/O  described  in  Section  III  (beginning  on 
page  72)  are  presented  below.  The  tape  drive  is  assumed  to  be  ini- 
tialized to  the  values  of  the  parameters  shown  in  the  table  on  page 
89.  For  these  tests  the  operator  will  be  requested  by  the  system  to 
mount  a tape  having  the  identifier  "reel__id".  This  single  tape  re- 
quired for  the  tape  I/O  tests  can  be  any  scratch  tape.  An  attempt 
will  be  made  to  read  and  write  the  tape  at  several  different  access 
classes . 

Following  each  read_tape  and  write_tape  command  the  I/O  coordina- 
tor returns  information  regarding  the  number  of  requests  signalled  by 
the  c ymmand  and  the  number  of  requests  already  queued  for  input  or 
output.  It  is  assumed  that  there  are  separate  queues  for  reading  and 
writing  tapes  and  that  these  queues  are  initially  empty.  With  these 
assumptions  the  numbers  supplied  in  the  scripts  are  correct  and  should 
be  checked. 

TDT-1:  (from  terminal  t5) 

♦login  u7  p5  -auth  confidential ,c 1 ,c2  -bf 
Password: 

Your  authorization  is  confidential , cl ,c2. 

•»*»»» 

r 1551  0.760  2.498  47 

*write_tape  I0_TEST>0UTPUT  reel_id 
1 request  signalled,  0 already  queued 
r 1553  0.719  12.098  149 

tape:  Contents  of  OUTPUT  written  on  tape  reel_id. 

TDT-2 : (CONTINUE) 

*new_proc  -auth  unclassified ,c 1 ,c2 

*«*#«* 

Your  authorization  is  unclassified, cl ,c2. 

r 1554  0.941  9.554  119 

»write_tape  I0_TEST>N0_0UTPUT  reel_id 
1 request  signalled,  0 already  queued 
r 1555  0.258  0.420  23 

tape:  No  tape  is  written  as  a result  of  this  test. 
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TAPE  I/O  ( TDT) 


(continued 


TDT-3 : (CONTINUE) 

*new_proc  -auth  confidential , cl 

**•**» 

Your  authorization  is  confidential , c 1 . 

• ««»f  « 

r 1556  0.920  6.806  78 

*write_tape  I0_TEST>N0_0UTPUT  reel_id 
1 request  signalled,  0 already  queued 
r 1556  1.817  16.70*4  123 

tape:  No  tape  is  written  as  a result  of  this  test. 

TDT-4:  (CONTINUE) 

*new_proc  -auth  confidential  ,c  1 ,02,03,0*4,05 

«***»« 

Your  authorization  is  confidential  ,c  1 ,c2,c3fc*4 ,c5 . 

*#***« 

r 1557  0.920  6.806  78 

*write_tape  I0_TEST>N0_0UTPUT  reel_id 
1 request  signalled,  2 already  queued, 
r 1558  0.218  1.332  33 

tape:  No  tape  is  written  as  a result  of  this  test. 

TDT-5:  (CONTINUE) 

*new_proc  -auth  top_secret,c1 ,c2 

Your  authorization  is  top_secret,c1 ,c2. 

r 1559  0.921  6.806  78 

»write_tape  I0_TEST>NO_0UTPUT  reel_id 
1 request  signalled,  2 already  queued 
r 1560  1 .77*4  16.704  123 

tape:  No  tape  is  written  as  a result  of  this  test. 

TDT-6:  (CONTINUE) 

*new_proc  -auth  confidential ,c2,c3 


Your  authorization  is  confidential ,c2,c3. 


r 1560  0.920  6.806  78 
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(continued)  TAPE  I/O  (TDT) 

»write_tape  IO_TEST>NO_OUTPUT  reel_id 
1 request  signalled,  0 already  queued, 
r 1561  1.803  17.616  181 

tape:  No  tape  is  written  as  a result  of  this  test. 

TDT-7 : (CONTINUE) 

•new_proc  -auth  confidential ,c 1 ,c2 


four  authorization  is  confidential ,c 1 ,c2. 


r 1562  0.921  7.482  81 

*change_wdir  IO_TEST 
r 1563  0.604  3.234  12 

> *write_tape_test  S, 1 ,2>BAD_LEVEL  reel_id 

1 request  signalled,  2 already  queued, 
r 1563  1.817  16.704  153 

tape:  Error  message  indicating  inability  to  access  S, 1 ,2>BAD_LEVEL 
TDT-8:  (CONTINUE) 

> *wr ite_tape_test  C , 1 , 2 , 3>BAD_CATEG0RY  reel_id 

1 request  signalled,  2 already  queued, 
r 1564  1.817  28.020  163 

tape:  Error  message  indicating  inability  to  access  C, 1 , 2,3>BAD_CATEGORY 

TDT-9:  (CONTINUE) 

> *write_tape_test  BAD_ACL  reel_id 

1 request  signalled  2 already  queued, 
r 1564  0.233  2.678  54 

tape:  Error  message  indicating  inability  to  access  BAD_ACL 

TDT-10:  (CONTINUE) 

*read_tape  C, 1 ,2>TAPE_INPUT  reel_id 
1 request  signalled,  0 already  queued 
r 1553  0.719  12.098  149 

tape:  Tape  reel_id  read  into  segment  TAPE_INPUT,  a segment  created 
in  directory  C, 1 ,2. 
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TAPE  I/O  ( TDT) 


(continued ) 


TDT- 11:  (CONTINUE) 

*new_proc  -auth  unclassified, cl ,c2 


Your  authorization  is  unclassified, cl ,c2. 

r 1554  0.941  9.554  119 

*read_tape  IO_TEST>C, 1 ,2>TAPE_INPUT  ree  _id 
1 request  signalled,  0 already  queued 
r 1555  0.258  0.420  23 

tape:  No  tape  is  read  as  a result  of  this  test. 

TDT-12:  (CONTINUE) 

*new_proc  -auth  confidential ,c 1 

«•»»*• 

Your  authorization  is  confidential ,c 1 . 

*«»#•« 

r 1556  0.920  6.806  78 

*read_tape  I0_TEST>C , 1 , 2>TAPE_INPUT  reel_id 
1 request  signalled,  0 already  queued 
r 1556  1.817  16.704  123 

tape:  No  tape  is  read  as  a result  of  this  test. 

TDT-13:  (CONTINUE) 

*new_proc  -auth  confidential, cl ,c2,c3|C4,c5 

*»•**» 

Your  authorization  is  confidential, cl ,c2,c3,c4 ,c5. 
r 1557  0.920  6.806  78 

*read_tape  I0_TEST>C , 1 ,2>TAPE_INPUT  reel_id 
1 request  signalled,  2 already  queued, 
r 1558  0.218  1.332  33 

tape:  No  tape  is  read  as  a result  of  this  test. 

TDT-14:  (CONTINUE) 

*new_proc  -auth  top_secret ,c 1 ,c2 


Your  authorization  is  top_secret,c1 ,c2. 


r 1559  0.921  6.806  78 


- — — 
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(continued ) 


TAPE  I/O  ( TDT) 


*read_tape  IO_TEST>C, 1 ,2>TAPE_INPUT  reel_id 
1 request  signalled,  2 already  queued 
r 1560  1.774  16.704  123 

tape:  No  tape  is  read  as  a result  of  this  test. 

TDT-15:  (CONTINUE) 

*new_proc  -auth  confidential ,c2,c3 


Your  authorization  is  confidential ,c2,c3. 


r 1560  0.920  6.806  73 

read_tape  I0_TESr>C, 1 ,2>TAPE_INPUT  reel_id 
1 request  signalled,  0 already  queued, 
r 1561  1.803  17.616  1 8 1 

tape:  No  tape  is  read  as  a result  of  this  test. 

TDT-1 6:  (CONTINUE) 

*new_proc  -auth  confidential , cl  ,c2 


Your  authorization  is  confidential, cl ,c2. 


r 1562  0.921  7.482  81 

*change_wdir  I0_TEST 
r 1562  0.605  2.345  12 

> *read_tape_test  S, 1 ,2>BAD_LEVEL  reel_id 

1 request  signalled,  2 already  queued, 
j r 1563  1 .817  16.704  153 

| 

tape:  Error  message  indicating  inability  to  access  S 
TDT-17:  (CONTINUE) 

> •read_tape_test  C, 1 ,2, 3>BAD_CATEG0RY  reel_id 

1 request  signalled,  2 already  queued, 
r 1564  1.817  28.020  163 

1 

tape:  Error  message  indicating  inability  to  access  C 


kJ 


1 ,2>BAD_LEVEL 


1 ,2,3>BAD_CATEG0RY 


1 

yj 
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TAPE  I/O  (TDT) 


(concluded) 


TDT-16:  (CONTINUE) 

> *read_tape_test  C,  1 ,2>BAD_WRITE_ACL  reel_id 
1 request  signalled  2 already  queued, 
r 1564  0.233  2.676  54 


tape:  Error  message  indicating  inability  to  access  BAD_ACL 

TDT- 1 9 : (CONTINUE) 

•print  C, 1 ,2>TAPE_INPUT 


TAPE_INPUT  06/21/75  1565.3  edt  Mon 


This  segment  contains  proper  information  for  output. 

r 1565  0.265  1 .222  32 

•delete  C , 1 , 2>TAPE_INPUT 
r 1566  0.160  4.686  82 

OPERATOR:  (CLEANUP) 

Delete  all  read_tape  and  write_tape  requests  from  the  tape 
daemon  queues. 


SYSTEM  SECURITY  ADMINISTRATOR  (SSA) 

The  SSA  tests  as  described  on  page  76  are  performed  manually  by 
the  SSA  himself.  In  the  sample  script  below,  it  is  assumed  that  the 
SSA  has  the  user  name  of  SSA  and  project  id  of  SysAdmin.  Reference  is 
made  to  the  directory  SSA_TEST,  created  during  initialization. 

SSA-1:  “login  SSA  -auth  confidential 
Password: 

«»**»! 

Your  authorization  is  confidential. 

r 1200  3.^53  12.354  345 

*list_acl  >system_library_1  >systom_privilege_ 

re  SSA. SysAdmin.* 

re  * .SysDaemon.* 

r 1201  0.123  1.234  67 

(Note  that  the  ACL  may  not  be  exactly  like  that  above,  depend- 
ing on  who  should  have  access  to  the  system_privilege_  gate.) 

SSA-2 : (CONTINUE) 

> *access  SSA_TEST 

no  privileges 
r 1202  0.123  0.343  23 

SSA-3 : (CONTINUE) 

*set_system__priv  dir 
r 1202  0.123  0.345  12 

> *access  SSA_TEST 

dir 

r 1202  0.012  0.233  45 

SSA-4:  (CONTINUE) 

*set_system_priv  “dir  seg 
r 1202  0.123  0.345  12 

> “access  SSA_TEST 

seg 

r 1202  0.012  0.233  45 

SSA-5:  (CONTINUE) 

*set_system_priv  "seg  ipc 
r 1202  0.123  0.345  12 
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SYS T tv!  SECURITY  ADMINISTRATOR  (SSA)  (continued) 

(For  this  test,  the  SSA  must  locate  some  user  logged  in  at  an 
authorization  below  his  own.  Assume  the  user  is  ul  on  project 
Pi.) 

*send_message  ul  pi  Hello, 
r 1202  1 .089  2.343  45 

(ul.pl  should  receive  this  message,  thereby  indicating  ipc 
privilege  is  set.) 

> *access  SSA_TEST 

no  privileges 
r 1202  0.012  0.233  45 

SSA-t:  (CONTINUE) 

*set_system_priv  "ipc  ringl 
r 1202  0. 123  0.345  12 

*send_message  ul  pi  Hello 

send_message : Attempt  to  wakeup  a process  of  a lower  authorization, 
r 1202  0.323  5.635  20 

(ul.pl  should  not  receive  this  message.) 

> *access  SSA_TEST 

ringl 

r 1202  0.012  0.233  45 

S3A-7 : (CONTINUE) 

*set_system_priv  “ringl  soos 
r 1202  0.123  0.345  12 

> *access  SSA_TEST 

soos 

r 1202  0.012  0.233  45 

SSA-8:  (CONTINUE) 

*set_system_priv  "soos 
r 1202  0.123  0.345  12 

> *access  SSA_TEST 

no  privileges 
r 1202  0.012  0.233  45 
•logout 

3SA-9:  *login  SSA 
•Password: 
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(continued)  SYSTEM  SECURITY  ADMINISTRATOR  (SSA) 


r 1200  1 .234  5.676  98 

*create_dir  test_dir 
r 1201  2.323  0.564  21 

*mbx_create  test_dir>sys_seg 
r 1202  3-424  9-467  23 

•create  test_dir>seg 
r 1203  3.424  7.543  90 

*reclassify_sys_seg  test_dir>sys_seg  confidential 
r 1204  1 .234  6.545  78 

•status  test_di r>sys_seg  -mode 

mode:  null 

ring  brackets:  1,1,1 

access  class:  confidential 

r 1205  1.121  4.345  56 

SSA-10:  (CONTINUE) 

*reclassify_seg  test_dir>seg  confidential 
r 1206  1.232  3.432  34 

•status  test_dir>seg  -mode 

mode:  null 

ring  brackets:  4,  4,  4 

access  class:  confidential 

r 1207  0.434  1 .232  78 

SSA-11:  (CONTINUE) 

*new_proc  -auth  confidential 


Your  authorization  is  confidential 

*««••• 

r 1208  1.234  56.765  58 

*reclassify_dir  test_dir  -auth  confidential  -quota  3 
r 1208  0.232  0.754  45 

•status  test  dir  -mode 
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SYSTEM  SECURITY  ADMINISTRATOR  (SSA) 


(concluded) 


mode:  null 

ring  brackets:  7,  7 

access  class:  confidential 

r 1209  0.121  0.323  33 

SSA-12:  (CONTINUE) 

*reclassify_dir  test_dir  confidential  -quota  0 
r 1210  1 .434  4.323  23 

•list  -pn  test_dir 

list:  There  was  an  attempt  to  reference  a directory  which  is 
out  of  service.  test_dir 
r 1211  1.212  4.345  34 

*reset_soos  test_dir 

reset_soos:  The  directory  is  upgraded  without  terminal  quota. 
test_dir 

r 1212  1 .232  0.656  45 

*reclassify_dir  test_dir  confidential  -quota  3 
r 1213  1.232  4.234  56 

*reset_soos  test_dir 
r 1213  4.323  6.765  45 

•list  -pn  test_dir 

Segments  = 2,  records  = 0. 

r w 0 seg 

0 sys_seg 

r 1215  3.234  0.233  34 
•logout 

See  Appendix  III  for  a writeup  of  the  access  command  used  to  de- 
termine which  privileges  are  set. 
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AUDITING  (AUD) 

The  tests  of  the  audit  mechanism  described  on  page  79  are  per- 
formed by  the  SSA,  or  someone  who  has  phcs_  access  so  that  the 
print_syserr_log  command  can  be  used.  The  test  consists  of  a single 
call  to  an  exec_com  which  should  invoke  each  of  the  audit  functions. 
It  is  assumed  that  all  of  the  audit  bits  are  set  on  for  the  current 
user  before  the  user  logs  in. 

•login  SSA  -auth  S,1,2 

Password : 

«»*•«* 

Your  authorization  is  secret,  cl,  c2 


r 1209  4.543  12.694  457 
> *exec_com  audit  DIR  SEG 
Segments  = 0. 

No  mail. 

•Enter  name  of  user  logged  in  below  S,1,2:  ul 
•Enter  his  project:  pi 

send_message : Attempt  to  wa^ceup  a process  of  a lower  authorization, 
mail:  Mailbox  full.  >udd>SysAdmin>SSA>S3A .mbx 

SYSERR_L0G  FROM  01/01/75  1209.0  edt  Mon  to  01/01/75  1230.0  edt  Mon. 

AUD-1:  (not  implemented) 

AUD-2:  (not  implemented) 

AUD-3:  (not  implemented) 

AUD-4:  Incorrect  access  to  [pd]>audit_dir 

AUD-5:  Illegal  procedure:  illegal_procedure  by  >udd>SysAdmin>SSA>audit 

AUD-6:  Access  violation:  no_write_permission  by  >udd>SysAdmin>S3A>audit 

AUD-7:  Access  violation:  not_in_read_bracket  by  >udd>SysAdmin>SSA>audit 

AUD- 8:  Wakeup  denied  by  SSA. SysAdmin,  referencing  ul.pl 

AUD-9:  System  privilege  enable:  dir 

System  privilege  disable:  dir 
AUD-10:  Reclassify_dir  >udd>SysAdmin>SSA>DIR 
AUD-1 1:  (not  implemented) 

AUD-12:  (not  implemented) 

AUD-1 3:  Message  segment  overflow  referencing  >udd>SysAdmin>SSA>SSA.mbx 
r 1239  12.354  4.565  344 
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AUDITING  (AUD) 


(concluded) 


The  arguments  DIR  and  SEG  are  the  names  of  a directory  and  seg- 
ment as  described  in  the  writeup  of  audit. ec  in  Appendix  III, 

The  exact  text  of  the  thirteen  audit  messages  that  should  appear 
(labeled  AUD-1  to  AUD-13)  is  not  shown  above  because  of  the  numerous 
variations  likely  to  be  encountered  in  the  audit  messages,  and  because 
the  exact  nature  of  the  messages  has  not  been  completely  finalized  at 
the  time  of  this  writing.  However,  the  approximate  content  of  each 
message  is  indicated.  Those  messages  indicated  as  not  implemented  are 
auditing  functions  that  have  not  yet  been  incorporated  into  llultics. 

If  these  functions  are  incorporated  in  the  future,  messages  will  ap- 
pear in  their  place. 

The  code  that  invokes  each  specific  auditing  function  can  be 
found  in  the  listings  of  the  program  audit.pl  1 and  aim_test_exec_coms 
in  Appendix  IV. 


APPENDIX  III 
PROGRAM  DOCUMENTATION 


This  appendix  contains  writeups  of  all  commands,  exec_coms  and 
subroutines  referenced  in  the  initialization  in  Appendix  I,  in  the 
test  scripts  in  Appendix  II,  or  internally  by  another  command  or  sub- 
routine, that  are  not  part  of  the  standard  Multics  system  as  documen- 
ted in  the  Multics  Programmers'  Manual  [10].  The  writeups  labeled 
"Exec_com"  or  "Command"  are  called  directly  by  the  user.  Those  la- 
beled "Active  Function"  or  "Subroutine"  are  internal  interfaces  refer- 
enced by  an  exec_com,  command,  or  other  subroutine.  These  writeups 
appear  in  alphabetical  order.  Below  is  a table  showing  the  corre- 
spondence between  the  writeup  in  this  appendix  and  the  name  of  the 
source  module  containing  that  program.  Appendix  IV  contains  the  actu- 
al listings  of  several  of  these  modules  explicitly  referenced  in  the 
scripts  or  text  in  Appendix  II,  or  containing  explicit  code  that  per- 
forms any  of  the  tests.  Those  modules  whose  listings  are  included  are 
indicated  by  an  asterisk  in  the  table. 


writeup 


access 

acl_comparison 

all 

assoc 

audit 

audit . ec 

authorization^ ester 
bit_to_integer_ 
check_status_ 
create_test_auth . ec 
create_test_di r.ec 
create_test_seg.ec 
create_test_start_up.ec 
di f fo_str 

dprint_test,  dpunch_test 
encode_authorization 
ge  t_c  al 1 ers_a  p_ 
get  dir  arg 
goto  seg 

line_number_inserter 

mbx_test.ec 

mbx_test_start_up.ec 


source  module 


access.pl 1 
acl_comparison . pi  1 
active_functions.pl  1 
assoc.pl  1 
•audit.pl  1 
*aim_test_exec_coms 
•authorization_tester.pl  1 
bit_to_integer_.pl 1 
check_status_.  pi  1 
*aim_test_exec_coms 
*aim_test_exec_c  oms 
•aim_test_exec_coms 
*aim_test_exec_coms 
diffo_str.pl 1 
dprint_test.pl 1 
active_functions.pl 1 
get_callers_ap_.pl 1 
ge  t_d  i r_a  r g_ . pi  1 
goto_seg_ .aim 
line_number_inserter.pl 1 
*aim_test_exec_coms 
•aim  test  exec  corns 
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new_proc_ 
new_proc_test 
number_ 
print_acl 
process_1_proc 
process_2_proc 
quota 

quota_used 
read_tape_test , write_tape 
response_to_start_up 
short_string 
termi nal_2_proc 
test_acl_use 
test_add_list 
t es  t_a  p pend_l i s t 
test_delete_list 
test_dir_auth 
test_ipc 

test_replace_list 
test_seg  acl 
test  seg  auth 
tipc_set_up 
t ry_d  i r_r  eference_ 
try_reference_ 


new_proc_.pl  1 
new_proc_test.pl  1 
number_.pl  1 
print_acl . pi  1 
•process_1_proc.pl  1 
•process_2_proc.pl 1 
active_functions.pl 1 
act ive_f unctions  . pi  1 
test  read_tape_test.pl  1 
•response_to_start_up.pl 1 
active_f  unctions .pi  1 
•termi nal_2_proc.pl  1 
test_acl_use.pl 1 
test_add_list.pl  1 
test_append_list.pl  1 
test_delete_list.pl 1 
•test_dir_auth.pl 1 
*test_ipc . pi  1 
test_replace_list.pl 1 
test  seg_acl . pi  1 
•test_dir_auth.pl 1 
•tipc_set_up.pl  1 
•try_dir_reference_.pl 1 
try_reference_.pl 1 


Command 


Name : access 

This  command  determines  experimentally  which  privilege  bits  are 
currently  set  for  the  process.  The  following  privileges  are  checked: 
dir,  seg,  soos,  and  ringl.  The  ipc  privilege  is  not  tested,  since 
that  can  much  more  easily  be  checked  by  using  the  send_messa-e  com- 
mand. The  user  need  not  have  access  to  the  system_privilege_  gate  to 
execute  this  command,  but  in  that  case  the  privileges  could  probably 
never  have  been  set. 

Usage 

access  dir 


1 ) dir 


is  the  pathname  of  a special  directory  that  is  accessed 
by  this  command  in  order  to  determine  which  privileges 
are  set.  The  contents  of  this  directory  is  given  in 
Notes  below. 


Notes 

The  privilege  bits  that  are  set  are  printed  on  the  terminal.  If 
no  privileges  are  set,  the  message  "no  privileges"  will  appear. 

The  directory  referenced  by  this  command  should  be  an  upgraded 
directory  at  a higher  access  class  than  the  current  process.  It 
should  contain  one  empty  segment  named  SEG,  an  empty  message  segment 
named  MSEC,  and  an  empty  subdirectory  DIR  that  is  out  of  service. 


acl_comparison 


acl_comparison 


Subroutine 

Name : acl_comparison 

The  acl_comparison  subroutine,  given  two  segment  access  control 
lists,  will  compare  the  two  ACLs  entry  by  entry  to  see  whether  or  not 
they  are  identical. 


del  acl_comparison  entry  (1  (*)  aligned,  2 char(32),  2 bi t ( 36) , 
2 bit ( 36) , 2 fixed  bin(35),  1 (*)  aligned,  2 
char( 32) , 2 bi t ( 36) , 2 bit(36),  2 fixed  bin ( 35 ) , 
fixed  bin(35)); 

call  acl_comparison  (acl_1,  acl_2,  code); 

1)  acl_1  is  a segment_acl  structure  as  described  in  the  MPM 

writeup  of  hcs_$add_acl_entries . (Input) 

2)  acl_2  is  a second  segment_acl  structure.  (Input) 

3)  code  indicates  the  results  of  the  comparison.  See  Notes 

below.  (Output) 

Notes 

Only  the  first  three  components  of  the  ACL  structure  (group_id, 
modes  and  zero_pad)  are  compared.  The  status_codes  are  not  compared. 
The  results  of  the  comparison,  indicated  by  the  value  of  code,  is  as 
f ol lows : 


0 

1 

2 

3 


The  ACLs  are  identical. 

The  ACLs  have  different  numbers  of  entries,  and  thus 
cannot  be  identical. 

There  exists  a pair  of  corresponding  entries  with 
different  group_id. 


acl_comparison 


acl_comparison 


There  exists  a pair  of  corresponding  entries  with 
different  zero_pad. 


I 


all  all 

Active  Function 

Name : all 


( 

This  active  function  returns  the  contents  of  a segment,  with  all 
newlines  except  the  last  one  changed  to  blanks. 


r 


i 


assoc 


assoc 


Command 


Name : assoc 

This  active  function  implements  an  associative  memory  useful  for 
implementing  exec_com  variables. 

Usage 


j 

r 

i 


[assoc  name] 

1)  name  is  a variable  which  has  been  set  to  some  value  by  a prior 
call  to  assoc_set. 

The  returned  value  is  a character  string  representing  the  value 
associated  with  the  supplied  name.  If  the  name  was  not  found,  a null 
string  is  returned. 

Name : assoc_set 

This  entry  is  used  to  associate  a value  with  a name  of  a varia- 
ble . 

Usage 


assoc_set  namel  value  1 ...  namen.  valuen. 

1)  namei.  is  a character  string  of  up  to  32  characters. 

2)  valuei.  is  a character  string  of  any  length.  Blanks  contained  in 

the  value  will  be  considered  part  of  the  value,  and  will  be 
returned  by  the  assoc  active  function  call.  Of  course,  if 
there  are  blanks  in  the  value,  the  value  must  be  enclosed  in 
quotes.  If  the  value_i  is  a null  string,  the  associative 
memory  entry  for  namei.  will  be  cleared. 

Name : assoc_clear 

This  entry  clears  the  entire  associative  memory. 

Usage 

assoc  clear 
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r 


assoc 


assoc 


There  are  no  arguments. 

Name : assoc_list 

This  entry  lists  the  associative  memory.  The  value  of  each  entry 
will  be  enclosed  in  quotes  (but  these  quotes  are  not  part  of  the 
value)  so  that  the  user  can  determine  if  there  are  any  leading  or 
trailing  blanks  as  part  of  the  value. 

Usage 


assoc_list 

There  are  no  arguments. 


1 
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audit 


audit 


Command 

Name : audit 

This  command  is  called  by  audit. ec  to  perform  several  operations 
that  are  more  easily  performed  by  a program.  It  should  not  be  called 
by  the  user. 

Usage 


audit  option 

1)  option  may  be  one  of  the  following: 


no_access 

creates  a directory  in  the  process  directory  with  null 
permission  and  attempts  to  access  it  with  hcs_$status_. 

ipr_f  ault 

attempts  to  execute  a privileged  instruction. 

acv_mode 

creates  a segment  in  the  process  directory  with  no 
write  permission  and  attempts  to  write  into  it. 

acv_ring 

attempts  to  read  the  contents  of 
>system_library_1>hcs_. 

no_attach 

attempts  to  attach  an  I/O  device. 

no_raount 

attempts  to  perform  an  rcp_  mount. 

i Notes 

The  names 
the  protection 
no_attach  have 

of  the  options  are  the  same  as  the  keywords  provided  to 
audit  commands.  Currently  the  keywords  no_mount  and 
no  effect. 
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audit. ec 


audit. ec 


Exec  com 


Name : audit. ec 


This  exec_com  tests  the  protection  audit  feature  of  Multics  by 
performing  13  operations,  each  of  which  should  be  audited  in  the 
syserr_log.  It  is  assumed  that  the  user  executing  this  exec_com  is 
logged  in  at  some  authorization  above  system_low,  and  that  he  has 
phcs_  access  so  that  he  can  print  the  syserr_log.  In  addition,  the 
user  must  have  access  to  the  system_privilege_  gate. 


exec_com  audit  dir  seg 

1)  dir  is  the  name  of  some  directory  with  an  access  class  equal  to 

the  current  authorization.  The  directory  may  or  may  not  be 
empty  — its  contents  are  not  affected, 

2)  seg  is  the  name  of  some  segment  with  an  access  class  equal  to 

the  current  authorization.  The  segment  snould  contain  about 
500  characters  of  ASCII  data.  The  contents  of  the  segment 
are  unaffected. 

Motes 

Several  messages  will  appear  on  the  terminal  when  this  exec_com 
is  invoked.  These  messages  may  be  ignored.  The  user  will  be  asked  at 
one  point  to  enter  the  name  and  project  of  some  other  user  on  the  sys- 
tem who  is  logged  in  below  the  current  authorization.  After  invoking 
all  the  auditing  functions,  the  print_syserr_log  command  is  used  to 
print  the  syserr_log  on  the  terminal.  There  should  be  one  message  in 
the  syserr_log  corresponding  to' each  of  the  following  events,  in  the 
following  order: 


1.  Initiate  of  classified  directory  dir. 

2.  Initiate  of  classified  segment  seg. 

3.  Initiate  of  message  segment  (user's  mailbox). 

4.  Access  denied  to  a directory  "audit_dir"  in  the  process 
directory. 

5.  Illegal  procedure  fault. 

6.  Access  mode  violation  (no_write_permission)  referencing  a 
segment  "audit_seg"  in  the  process  directory. 


audit. ec 


audit. ec 


7.  Ring  bracket  violation  (not_in_read_bracket)  referencing 
>system_library_1>hcs_. 

8.  Wakeup  denied  referencing  process  of  user  at  lower  author- 
ization . 

9.  Enable  and  disable  of  directory  privilege  (2  messages). 

10.  Reclassification  of  dir. 

11.  Attach  of  I/O  device  denied. 

12.  Mount  denied. 

13.  Message  segment  overflow,  referencing  user's  mailbox. 
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authorization  tester 


authorization_tester 


Command 


Name : authorization_tester 

This  command  determines  the  authorization  of  the  current  process 
(level  number  and  category  set)  through  selected  references  to  classi- 
fied segments  in  a special  directory.  This  computed  authorization  is 
compared  to  that  supplied  by  a call  to  hcs_$get_authorization , and  an 
error  message  is  printed  if  both  are  not  the  same.  The  special  direc- 
tory is  created  by  the  use  of  the  exec_com  create_test_auth.ec. 

Usage 


authorization_tester  -dirname-  -control_args- 

1)  dirname  is  the  directory  that  is  assumed  to  contain  the  special 

subtree  required  by  authorization_tester . See  Notes 
below  for  a description  of  this  subtree.  If  dirname  is 
not  supplied,  it  will  be  assumed  to  be  the  working  di- 
rectory . 

2)  control_args  may  be  the  following: 

-max  auth  specifies  the  maximum  authorization  to  be  tested.  The 
default  is  system_high.  The  purpose  of  this  argument 
is  to  limit  the  number  of  directories  examined  in  the 
special  subtree.  If  the  current  process  authorization 
is  above  this  specified  value,  an  error  message  will  be 
printed . 


Notes 


The  directory  specified  by  dirname  must  contain  one  subdirectory 
of  each  classification  level  system_low  through  system_high  (no  cate- 
gories), and  one  subdirectory  of  each  of  the  categories  within  the 
category  set  of  system_high.  The  classification  level  of  the  category 
directories  may  be  any  level  below  the  current  process  level,  but 
should  typically  be  system_low. 

The  name  of  each  of  these  directories  is  the  short  name  for  its 
authorization,  as  returned  by  the  subroutine 

convert  authorization  $to_string^  short,  followed  by  the  suffix 
"_auth" . Each  of  the  subdirectories  also  contains  a single  zero 
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length  segment  whose  name  is  ”seg" . This  entire  subtree  can  be  creat- 
ed by  create_test_auth.ec. 


The  authorization_tester  works  by  trying  to  initiate  segments  of 
successively  higher  levels,  beginning  with  system_low  and  ending  with 
the  maximum  level  as  specified  above.  The  current  level  is  assumed  to 
be  the  highest  level  that  was  successfully  initiated  and  read.  Simi- 
larly, the  current  category  set  is  the  logical  intersection  of  all  the 
categories  that  could  be  read. 

After  determining  the  current  level  and  category  set,  higher  lev- 
els and  other  category  sets  are  read  to  check  that  no  access  is  al- 
lowed to  these.  Only  read  access  is  actually  checked.  To  check  if  a 
"write  down"  or  "write  up"  is  allowed  the  test_seg_auth  command  must 
be  used. 


b i t_t  oj.  n t eg  e r_ 


bit_to_integer_ 


Subroutine 


Name : bit_to_integer_ 


This  function  returns  a character  string  consisting  of  a series 
of  integers  separated  by  commas  that  indicate  which  positions  of  a bit 
string  have  1 's. 

Usage 

declare  bit_to_integer_  entry  ( bit ( * ) ) returns  (char(*)); 
charstring  = bit_to_integer_  (bitstring); 

1)  bitstring  is  a string  of  bits.  This  string  may  be  any  length. 

( Input) 

2)  charstring  is  the  string  containing  integers  corresponding  to  bit 

positions  in  bitstring  that  have  1's.  This  string 
should  be  long  enough  to  hold  the  maximum  number  of  in- 
tegers that  are  expected.  If  bitstring  is  zero  in 
length,  or  contains  no  1's,  the  string  "none"  will  be 
returned . 

Example 

call  ioa_  (bit_to_integer_(" 100011 1"b) ) ; 
will  produce  the  following  output: 


1,5, 6, 7 
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check  status 


check  status 


Subroutine 


Name : check_status_ 

This  subroutine  is  called  by  try_dir_reference_  in  order  to  vali- 
date the  status  code  returned  on  each  call  to  an  hcs_  entry  under 
test.  This  subroutine  prints  an  error  message  if  the  status  code  is 
not  as  expected. 

Entry : check_status_$set 

This  entry  initializes  static  data  consisting  mostly  of  pointers 
to  variables  in  try_dir_reference_.  It  is  used  so  that  the  variables 
themselves  do  not  have  to  be  passed  as  arguments  on  each  call  to 
check_status_. 

Usage 


del  check_status_$set  entry  (bit(2),  bit(2),  ptr,  ptr,  ptr,  ptr, 
label ) ; 

call  check_status_$set  (mode_tested , mode_expected , code_ptr, 
allowed_code_ptr , not_allowed_code_ptr , reference_ptr , 
return_label) ; 

1)  mode_tested  is  either  "10"b  for  modify,  or  "01"b  for  status.  This 

argument  describes  the  access  mode  currently  being  tested. 
Its  relationship  to  mode_expected  is  described  in  Notes . 

( Input) 

2)  mode_expected  specifies  the  access  mode  that  is  expected  on  the  di- 

rectory being  tested.  The  first  bit  indicates  modify,  and 
the  second  bit  indicates  status.  In  addition  to  either  bit, 
both  bits  or  none  (for  no  access)  may  be  on.  Since  any  one 
invocation  of  try_dir_reference_  only  checks  one  directory, 
this  value  normally  never  changes.  (Input) 

3)  code_ptr  is  a pointer  to  the  status  code  argument  (fixed  bin(35)) 

returned  from  a previous  call  to  the  hcs_  entry  being  test- 
ed. (Input) 

4)  allowed_code_ptr  is  a pointer  to  the  status  code  that  will  be  ex- 

pected when  mode_tested  is  included  in  mode_expected . In 
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other  words,  if  the  access  mode  being  tested  is  allowed, 
this  status  code  should  be  returned  by  the  call  to  the  hcs_ 
entry.  For  most  legitimate  calls,  there  should  be  no  status 
code,  and  therefore  this  argument  will  point  to  a zero  word. 
( Input) 

5)  not_allowed_code_ptr  is  a pointer  to  the  status  code  expected  when 

mode_tested  is  not  included  in  mode_expected . For  example, 
if  only  "s"  permission  is  expected  on  a directory  under 
test,  and  mode_tested  is  "m",  this  argument  points  to  the 
expected  code.  (Input) 

6)  reference_ptr  is  a pointer  to  a string  (char(l68))  that  describes 

the  item  being  referenced  in  the  hcs_  call.  This  string  is 
printed  along  with  any  error  message.  (Input) 

7)  return_label  is  a label  in  try_dir_reference_  to  which 

check_status_  will  return  in  the  case  of  any  error.  (Input) 


Notes 


The  only  function  of  this  entry  is  to  save  each  of  the  above 
pointers  and  variables  for  later  use  by  check_status_.  Where  pointers 
are  specified,  only  the  pointers  are  saved.  The  values  of  the  varia- 
bles pointed  to  may  be  freely  changed  between  calls  to  check_status_. 
In  try_dir_reference_,  this  entry  is  called  only  when  mode_tested 
needs  to  be  respecified,  since  none  of  the  other  items  ever  change. 

Entry : check_status_ 

This  is  the  entry  that  is  called  on  each  test  of  an  hcs_  entry. 


Usage 

del  check_status_  entry  options  (variable); 

call  check_status_  (line_no,  entry_no,  error_bit,  ctl_string, 
ctl_argj.,  ...,  ctl_argii); 

is  the  line  number  (fixed  bin)  in 
try_dir_reference_  in  which  the  call  to 
check_status_,  or  some  internal  support  procedure, 


1 ) 1 i ne_no 
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2)  entry_no 


3)  error_bit 


4)  ctl_string 


5)  ctl_argi 


was  made.  This  line  number*  is  printed  along  with 
any  error  message.  (Input) 

is  an  index  (fixed  bin)  into  a table  of  names  of 
hcs_  entry  points.  The  table  is  shown  in  Entry 
Names  below.  (Input) 

This  bit  (bit(1))  on  indicates  that  a special  mes- 
sage is  to  be  printed  even  though  the  proper  sta- 
tus code  may  have  been  received.  If  the  wrong 
status  code  was  received,  the  normal  message  is 
printed  as  described  in  Notes  below.  (Input) 

is  the  message  (char(*))  to  be  printed  when 
error_bit  is  on  and  the  proper  status  code  is  re- 
ceived. This  message  is  in  the  form  of  ioa_ 
control  string,  and  may  be  followed  by  more  argu- 
ments for  ioa_.  (Input) 

are  possible  additional  arguments  for  ioa_.  (In- 
put) 


Notes 


If  an  error  is  detected,  check_status_  prints  a message  on 
user_output  and  returns  to  the  label  specified  in  check_status_$set. 

If  there  is  no  error,  check_status_  just  returns  from  the  call. 

The  error  conditions  detected  are  described  below.  Each  condi- 
tion is  described  in  terms  of  a logical  expression  relating  the  values 
of  several  variables.  Following  the  condition,  the  text  of  the  error 
message  is  shown,  where  the  following  substitutions  should  be  made  for 
each  item  enclosed  in  quotes: 

"Status/Modify"  "Status"  if  mode_tested  = "01"b 
"Modify"  if  mode_tested  = "10"b 

"code"  Standard  error_table_  message  corresponding  to 

the  status  code  pointed  to  by  code_ptr. 

"allowed_code"  Message  corresponding  to  the  status  code 
pointed  to  by  allowed_code_ptr . 
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"not_allowed_code"  Message  corresponding  to  the  status  code 
pointed  to  by  not_allowed_code_ptr . 

"message"  Message  composed  of  the  ctl_string  and 

ctl_args  passed  to  check_status_. 

1.  (mode_expected  4 mode_tested)  = "00"b  4 (code  = 0) 

"Status/Modify"  permission  was  not  expected  (status  code 
"not_allowed_code"  expected),  but  no  status  code  returned. 

2.  (mode_expected  & mode_tested)  = "00"b  4 (code  = not_allowed_code)  4 
error_bit 

"Status/Modify"  permission  was  not  expected,  and  proper  status  code 
returned,  but  "message". 

3.  (mode_expected  4 mode_tested)  = "00"b  4 (code  l 0)  4 (code  i 
not_al lowed_code) 

"Status/Modify"  permission  not  expected,  but  status  code  "code"  was 
returned  instead  of  "not_allowed_code" . 

<4.  (mode_expected  4 mode_tested)  l "00"b  & (code  i allowed_code)  & 
(code  = 0) 

"Status/Modify"  permission  and  status  code  "allowed_code"  expected, 
but  none  returned. 

5.  (mode_expected  & mode_tested)  i "00"b  & (code  i allowed_code)  & 
(code  i 0)  4 (allowed_code  = 0) 

"Status/Modify"  permission  expected  --  status  code  "code"  returned 
instead . 

6.  (mode_expected  & mode_tested)  i "00"b  & (code  l allowed_code)  4 
(code  i 0)  4 (allowed_code  i 0) 

"Status/Modify"  permission  and  status  code  "allowed_code"  expected, 
but  "code"  returned  instead. 
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If  none  of  the  above  conditions  occurs,  no  error  message  is  printed 
and  check_status_  returns.  The  "no  error"  condition  can  be  expressed 
as: 

(mode_expected  & mode_tested)  i "00"b  & (code  = allowed_code) 
or  (mode_expected  & mode_tested)  = "00"b  & (code  = not_allowed_code) 
& (error_bit  = "0"b) 

Following  any  error  message,  a line  of  the  following  form  is  printed: 

Error  occurred  on  a call  to  "entry_name" , referencing  "reference" 
(on  line  "line_no"  of  try_dir_reference_) . 

where 

"entry_name"  is  the  name  of  the  hcs_  entry  corresponding  to 

the  entry_no  argument. 

"reference"  is  the  reference  string  passed  to 

check_status_. 

"line_no"  is  the  value  of  the  line_no  argument. 

Entry : check_status_$return,  check_status_$no_return 

These  two  entries  turn  on  or  off  a flag  designating  whether 
check_status_  should  return  to  its  caller,  or  to  return_label , in  case 
of  an  error.  The  effect  of  specifying  return  is  to  continue  testing 
regardless  of  errors  that  are  detected.  These  entries  are  not  called 
by  try_dir_reference_,  but  from  command  level  by  the  user.  Default  is 
no_return,  which  says  to  exit  to  return_label  in  case  of  an  error. 

Entry : check  status  $debug  on.  check  status  Idebug  off 

These  two  entries,  also  called  from  command  level,  turn  on  or  off 
a switch  causing  check_status_  to  print  a line  of  information  on  every 
call,  instead  of  only  on  errors.  The  line  has  the  following  format: 

***("line_no" ) ; "entry_name"  "reference" 

where  "line_no",  "entry_name" , and  "reference"  are  defined  above. 
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In  addition,  each  time  check_status_$set  is  called,  a new  page  is 
ejected  followed  by  a line  of  the  following  form: 

where  "Status/Modify"  is  as  defined  above. 

Entry  Names 


The  following  table  lists  the  number  and  name  of  each  entry  point 
in  hcs_  whose  entry  number  can  be  passed  as  the  entry_no  argument  to 
check  status  . 


Name  entry_no 


hcs_$aa J_acl_entries  1 

ncs_$add_dir_acl_entries  2 

hcs_$add_dir_inacl_entries  3 

hcs_$add_inacl_entries  4 

hcs_$append_branch  5 

hcs_$append_branchx  6 

hcs_$append_link  7 

hcs_$chname_file  8 

hcs_$chname_seg  9 

hcs_$del_dir_tree  10 

hcs_$delentry_file  11 

hcs_$delentry_seg  12 

hcs_$delete_acl_entries  13 

hcs_$delete_dir_acl_entries  14 

hcs_$delete_dir_inacl_entries  15 
hcs_$delete_inacl_entries  16 

hcs  $fs  get  mode  17 

he  s_$  f s ge  t_pa  t h_name  1 8 

he  s_$  f s_ge  t_r  e f_name  1 9 

hcs  $fs  get  seg  ptr  20 

hcs_$fs_move_file  21 

hcs_$fs_move_seg  22 

hcs  $fs  search  get  wdir  23 

hcs_$fs_search_set_wdir  24 

hcs_$get_author  25 

hcs_$get_bc_author  26 

hcs  $get  dir  ring  brackets  27 
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he  s_$ge  t_rna  x_l  e ngt  h 

28 

hcs_$get_process_usage 

29 

hes  $get  ring  brackets 

30 

hcs_$get_safety_sw 

31 

hcs_$get_search_rules 

32 

hcs_$initiate 

33 

hcs_$initiate_count 

34 

hcs_$initiate_search_rules 

35 

hcs_$list_acl 

36 

hcs_$list_dir_acl 

37 

he  s_$  1 i s t_d  i r_i  nac  1 

38 

hcs_$list_inacl 

39 

hcs_$make_ptr 

40 

hcs_$make_seg 

41 

he  s_$  q uo  t a_ge  t 

42 

he  s_$  q uo  t a_mo  ve 

43 

hcs_$replace_acl 

44 

hcs_$replace_dir_acl 

45 

hcs_$replace_dir_inacl 

46 

hcs_$replace_inacl 

47 

hcs_$reset_working_set 

48 

hcs_$set_bc 

49 

he  s_$  s e t_b  c_s  eg 

50 

he  s_$  s e t_di  r_r  i ng_b  r acke  t s 

51 

he  s_$  s e t_ma  x_l  e ngt  h 

52 

he  s_$  a e t_max_l e ngt  h_s  eg 

53 

he s_$ s e t_r i ng  bracke t s 

54 

he  s_$  s e t_s  a f e ty_sw_s  eg 

55 

he  s_$  s e t_s  a f t ey_sw 

56 

hcs_$star_ 

57 

he  s_$  s t ar_l i s t_ 

58 

hcs_$status_ 

59 

hcs_$status_long 

60 

hcs_$status_minf 

61 

hcs_$status_mins 

62 

hcs_$terminate_file 

63 

hcs_$tenninate_name 

64 

hcs_$terminate_noname 

65 

hcs_$terminate_seg 

66 

hcs_$truncate_file 

67 

hcs_$  t runca te_seg 

68 
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Subroutine 


Name : conv 


This  procedure  returns  a character  string  representation  of 
certain  PL/I  data  types. 

Entry : conv_$fb 

This  entry  returns  the  character  representation  of  a fixed 
bin(35)  number. 

Usage 

del  conv_$fb  entry  (fixed  bin(35))  returns  (char(20)); 
string  = conv_$fb  (n); 

1)  n is  the  number  whose  value  is  to  be  converted.  (Input) 

2)  string  is  the  number  represented  as  a character  string,  left 

justified.  If  the  value  of  n is  -1,  this  string  will 
have  the  value  "not  returned" . 

Entry : conv_$ptr 

This  entry  returns  the  value  of  a pointer,  , 


Usage 


del  conv_$ptr  entry  (ptr)  returns  (char(20)); 
string  = conv_$ptr  (ptr); 


1)  ptr 


is  the  pointer  to  be  converted.  (Input) 


2)  string  is  the  value  of  the  pointer,  in  the  format  as  produced 

by  the  "~p"  specification  of  ioa_.  If  the  pointer  is 
null,  the  string  "not  returned"  is  returned. 
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Exec  com 


Name : create_test_auth.ec 

This  exec_com  creates  the  subtree  required  for  the 
authorization_tester  command. 

Usage 


exec_com  create_test_auth  path  "(classj.  ...  classy)" 

1 ) path  is  the  pathname  of  the  directory  to  be  created,  in 

which  directories  of  various  access  classes  will  ap- 
pear . 

2)  classi.  are  the  names  of  each  of  the  levels  and  each  of  the 

categories  within  system_high  (except  system_low),  sep- 
arated by  spaces,  and  enclosed  in  parentheses  and 
quotes  as  shown.  The  order  is  unimportant.  The  user 
must  be  able  to  new_proc  to  each  of  these  authoriza- 
tions . 

Notes 


The  operation  of  this  exec_com  is  very  similar  to  the  operation 
of  create_test_dir.ec  and  create_test_seg.ec.  See  the  writeup  of 
create_test_dir.ec  for  a description. 

The  subtree  created  is  illustrated  on  the  next  page. 
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Exec_com 

Name:  create_test_dir.ec 

This  exec_com  creates  the  special  directory  required  for  the 
test_dir_auth  command. 

Usage 


exec_com  create_test_dir  path  -acc  classl  class2  class3  class4 
class5  class6 

1)  path  is  the  pathname  of  the  directory  to  be  created.  If  it  al- 

ready exists,  the  user  will  be  asked  whether  he  wishes  to 
delete  the  old  copy. 

2)  -acc  is  a control  argument  followed  by  the  access  classes  of  the 

six  subdirectories  in  path  that  are  to  be  created.  These 
access  classes  may  be  any  values  that  have  a specific  rela- 
tionship to  the  authorization  at  which  test_dir_auth  is  to 
be  run.  See  Notes  below. 

Notes 

If  the  home  directory  contains  a segment  named  "create_test_acl" , 
that  segment  is  assumed  to  contain  a list  of  access  identifiers,  one 
per  line,  that  are  to  be  placed  on  the  ACLs  of  the  segments  and  direc- 
tories created  by  this  exec_com.  If  that  segment  does  not  exist,  only 
the  current  user  will  be  given  access.  It  is  important  to  realize 
that  the  test_dir_auth  command  will  only  operate  properly  if  the  user 
is  on  the  ACL  of  all  the  directories  and  segments  created  by  this 
exec_com.  The  actual  access  modes  should  not  be  specified  in 
create_test_acl . 

This  exec_com  creates  upgraded  directories  at  the  six  access 
classes  by  performing  new_procs  to  each  of  the  authorizations  repre- 
sented by  the  classi.  arguments.  In  order  for  this  exec_com  to  work 
properly,  the  exec_com  create_test_start_up.ec  should  be  called  at 
each  of  these  new_procs.  Such  a call  can  be  safely  placed  in  the  us- 
er's start_up.ec  (to  be  executed  at  new_proc  time)  because  it  will 
have  no  effect  unless  create_test_dir.ec  was  called  last  in  the  previ- 
ous process,  or  if  the  process  is  at  system_low.  The  user  may  quit 
any  time  during  the  operation  of  these  exec_coms.  If  the  operation  is 
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to  be  aborted,  a manual  new_proc  to  system_low  will  return  the  user  to 
his  original  working  directory. 

The  call  to  create_test_dir.ec  must  be  made  from  a process  cur- 
rently at  system_low.  Several  temporary  segments  are  created  in  the 
user's  home  directory  that  are  used  to  drive  create_test_start_up.ec 
for  the  subsequent  processes.  One  of  these  segments,  called  "who", 
contains  the  name  of  the  original  exec_com  that  was  called  (in  this 
case  "create_test_dir" ) and  is  read  by  create_test_start_up.ec  to  de- 
termine what  operations  to  perform.  If  this  segment  "who"  is  not 
found,  no  action  will  be  performed.  After  all  the  directories  have 
been  created,  the  temporary  segments  will  be  deleted  and  the  process 
will  be  restored  to  system_low  in  the  original  working  directory  from 
which  create_test_dir.ec  was  called. 

Since  this  exec_com  performs  new _procs  to  each  of  the  six  author- 
izations specified  by  class_i,  the  user  must  be  allowed  to  new_proc  to 
these  levels.  The  following  table  lists  each  classi.  argument,  the 
name  of  the  directory  that  will  be  created  with  that  access  class,  and 
the  relationship  between  the  level  and  category  set  specified  for 
classi,  and  the  authorization  of  the  process  which  is  to  run 
test  dir  auth. 


level 

category  set 

directory  name 

classi 

lower 

equal 

lower_equal 

class2 

higher 

equal 

higher_equal 

class3 

equal 

equal 

equal_equal 

class4 

equal 

subset 

equal_subset 

class5 

equal 

superset 

equal_superset 

class6 

equal 

isolated 

equal_isolated 

The  table  above  indicates  which  access  class  is  to  be  specified  in  the 
command  line  for  each  classi  argument.  For  example,  the  value  of 
classA  should  be  an  access  class  that  has  an  equal  level  and  whose 
category  set  is  a subset  of  the  authorization  of  the  process  that  will 
be  running  test_dir_auth. 

If,  when  create_test_dir.ec  is  first  invoked,  the  directory  spec- 
ified by  path  already  exists,  the  user  will  be  asked  whether  he  wishes 
to  delete  it.  This  deletion  may  fail  if  the  directory  contains  non- 
empty upgraded  directories.  Such  directories  must  be  deleted  manually 
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by  a process  of  the  proper  authorization.  Alternatively,  system  priv- 
ileges "dir"  and  "seg"  can  be  set  (if  the  user  has  access  to  the 
system_privilege  gate),  and  this  exec_com  can  be  called  to  delete  the 
previously  existing  directory. 

The  structure  of  the  subtree  created  by  this  exec_com  is  illus- 
trated below: 


path 


lower_! 

! higher_] 

! equal_! 

equal  ! 
1 
1 

[equal  | 

1 1 

1 1 

! equal  ! 
1 1 

1 1 

I I I 


equal_! 

1 equal_  | 

1 equal_  ! 

subset ! 
1 
1 

[superset ! 

1 1 

1 1 

[isolated  1 
1 1 

1 1 

1 

1 

1 

1 

! 

i 

i 

1 

1 

1 

1 

II  II  II 


idir ! I seg ! Idir ! I seg!  Idir i I seg!  Idir ! ! seg!  idir ! !segj  ! dir ! !segj 
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Exec  com 


Name : create_test_seg.ec 

This  exec_com  creates  a special  directory  that  is  required  for 
the  test_seg_auth  command. 

Usage 


exec_com  create_test_seg  path  -acc  classl  class2  class3  class4 
class5  class6 

1)  path  is  the  path  name  of  the  directory  to  be  created.  If  it  al- 

ready exists,  the  user  will  be  asked  whether  he  wishes  to 
delete  the  old  copy. 

2)  -acc  is  a control  argument  which  must  appear,  followed  by  six  ac- 

cess class  arguments.  The  six  access  classes  are  the  access 
classes  to  be  assigned  to  the  six  subdirectories  within 
path,  and  have  a specific  relationship  to  the  authorization 
at  which  the  test  seg  auth  command  is  to  be  run.  See  Notes 
below . 

Notes 


The  operation  of  this  exec_com  is  very  similar  to  the  exec_com 
create_test_dir.ec.  The  exec_com  create_test_start_up.ec  should  be 
called  after  each  new_proc  performed  by  this  exec_com.  In  addition, 
the  segment  "create_test_acl"  in  the  home  directory  is  accessed  to  ob- 
tain the  names  for  the  ACL  of  the  directories  and  segments  to  be  cre- 
ated. For  a description  of  the  operation,  and  the  six  classi.  argu- 
ments, see  the  writeup  of  create_test_dir.ec. 

In  addition  to  the  requirements  specified  for  create_test_dir.ec, 
this  exec_com  expects  a segment  named  test_seg  auth  to  exist  in  the 
working  directory.  The  contents  of  this  segment  is  required  to  fill 
in  the  first  few  words  of  the  segments  created  by 
create_test_start_up.ec  on  behalf  of  this  exec_com  and  required  by 
t es  t_s  eg  au th . 

The  structure  of  the  subtree  created  by  this  exec_com  is  illus- 
trated below: 
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path 


lower_| 

equal  ! 
1 
1 

1 higherj 
! equal  | 
1 1 

! equal_] 
! equal  | 

1 I 

1 1 

! equal_| 
! subset ] 

1 I 

1 1 

! equal_  | 

! superset ' 
1 1 

equal_  | 

isolated ! 

1 

11  III  1 

1 1 1 1 l i 

1 di  r | 
1 1 

1 1 

! dir  ! 
1 1 
1 , „ 1 

i dir  ! 
1 1 

1 1 

' dir  | 

1 1 

1 1 

! dir  | 
1 1 

1 1 

' dir  J 
1 1 

j ' 1 i i i 

L — * J i i 

! seg  ! 

i ! 

! seg  ! 

i i 

i i 

! seg  | 
1 1 

1 1 

! seg  | 
1 1 

1 1 

! seg  | 
1 1 

1 seg  ! 
1 1 

The 

contents  of 

each  segment  named 

"seg"  will  be 

the  contents 

tne  segment  named  "test  seg  auth  " obtained  from  the  original  working 
di rectory . 
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Exec_com 

Name : create_test_start_up.ec 

This  exec_com  is  called  by  the  user  immediately  after  each 
new_proc  forced  by  the  use  of  create_test_dir.ec,  create_test_seg.ec 
or  create_test_auth.ec.  Calling  it  separately  will  usually  have  no 
effect . 

Usage 

exec_com  create_test_start_up 

Notes 

When  called,  this  exec_com  decides  what  to  do  based  on  informa- 
tion contained  in  various  segments  in  the  home  directory  and  on  the 
current  authorization.  A description  of  each  of  these  segments 
follows: 

1)  who  contains  the  name  of  the  original  exec_com  that  was 

called,  either  "create_test_dir , "create_test_seg",  or 
"create_test_auth" . 

2)  original_wdir  is  the  pathname  of  the  working  directory  from  which 

the  original  exec_com  was  called. 

3)  pathname  is  the  pathname  argument  to  the  original  exec_com. 

4)  ac_names  is  a string  of  the  form: 

$class_1_$dirnamej_$ . . .$classn.$dirnameji$ 

where  each  pair  $classi.$dirnamei.$  is  composed  of  the 
classi  argument  supplied  to  the  original  exec_com, 
transformed  into  a short  string,  and  the  name  of  the 
directory  that  was  created  with  that  access  class,  as 
defined  by  the  particular  exec_com  used. 

After  each  new_proc,  the  process  authorization  is  examined.  If 
it  is  system_low,  the  temporary  segments  above  (if  they  exist)  are  de- 
leted and  the  original  working  directory  (if  specified)  will  be  re- 
stored. If  not  system_low,  the  segment  "who"  is  examined.  If  it  does 
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diffo  str 


Subroutine 


Name : diffo  str 


The  diffo_str  subroutine,  given  five  character  strings,  will  se- 
lect the  first  of  the  last  three  that  is  different  from  both  the  first 
two.  In  other  words,  if  you  have  two  character  strings  and  want  a 
string  that  is  different  from  them  both,  then  you  must  supply  three 
candidate  strings.  This  subroutine  will  then  pick  the  first  one  of 
the  candidates  that  is  different  from  both  of  your  two  original 
strings. 

Usage 

del  diffo_str  entry  (char(*),  char(*),  char(*),  char(*),  char(*), 
char(*),  fixed  bin(35)); 

call  diffo_str  (str_1,  str_2,  str_3,  candidate_1 , candidate_2, 
candidate_3,  code); 


1)  str_1 

2)  str_1 

3)  str_3 


4)  candidate_1 

5)  candidate_2 

6)  candidate_3 

7)  code 


is  a character  string.  (Input) 
is  a character  string.  (Input) 

If  code  is  0,  then  this  is  the  first  of  the  strings 
candidate_1,  candidate_2,  candidate_3  that  is  differ- 
ent both  from  str_1  and  str_2  above.  If  code  is  not 
0,  then  this  value  is  undefined.  See  Status  Code 
Values  below.  (Output) 

is  a character  string  of  length  less  than  or  equal  to 
the  length  of  str_3  above.  (Input) 

See  Candida te_1  above.  (Input) 

See  candidate_1  above.  (Input) 

is  a standard  status  code.  See  Status  Code  Values  be- 
low. (Output) 


i 
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Status  Code  Values 

The  values  mean  the  following: 

0 The  string  that  is  different  both  from  str_1  and 
str_2  is  contained  in  str_3. 

1 The  length  of  either  candidate_1 , candidate_2,  or 
Candida te_3  is  greater  than  the  length  of  str_3. 

2 Unsuccessful,  probably  the  three  candidate  strings 
were  not  three  different  strings. 


I 1 
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dprint_test 


Command 


Name:  dprint_test,  dpunch_test 

These  commands  operate  exactly  like  dprint  and  dpunch,  except 
that  no  check  is  made  if  the  user  or  SysDaemons  have  no  access  to  the 
segment  or  containing  directory,  or  if  the  segment  is  not  found.  The 
dprint  or  dpunch  request  is  always  queued. 
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Active  Function 

Name : encode_authorization 

This  active  function  returns  the  encoded  form  of  an  authorization 
string,  as  provided  by  convert_authorization_$encode . 

Usage 

[encode_authorization  auth_string] 

1)  auth_string  is  an  authorization  string.  It  must  be  enclosed  in 
quotes  if  it  contains  any  blanks. 

Notes 

Note  that  this  active  function  may  return  a null  string  for 
"system_low" , as  returned  by  convert_authorization_$encode . 


If  the  auth_string  is  invalid,  the  string  "**"  is  returned. 


ge  t_callers_ap_ 
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Subroutine 


Name : get_callers_ap_ 


This  subroutine  returns  a pointer  to  the  argument  list  of  the 
caller's  caller,  i.e.,  if  A calls  B and  B calls  C,  then  C can  get  a 
pointer  to  the  argument  list  that  A passed  to  B by  calling 
g e t_c a 1 1 e r s_a p_ . if  c wants  a pointer  to  its  own  argument  list  (the 
one  passed  to  it  by  B) , it  can  call  cu_$arg_list_ptr . 


Usage 


declare  get_callers_ap_  entry  returns  (pointer); 
ap  = get_callers_ap_  (); 

1 ) ap  is  a pointer  to  the  argument  list  of  the  caller's  caller. 
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Subroutine 

Name : get_dir_arg_ 

This  subroutine  gets  an  argument  from  the  caller's  argument  list 
and,  assuming  the  argument  is  the  pathname  of  a directory,  returns  the 
full  pathname  of  the  directory.  If  no  argument  is  found,  the  pathname 
of  the  working  directory  is  returned. 

Usage 

declare  get_dir_arg_  entry  (fixed  bin,  char(»),  fixed  bin(35)); 

call  get_dir_arg_  (argno,  dirpath,  code); 

is  the  number  of  the  argument  expected  to  be  a directo- 
ry name.  (Input) 

is  the  full  absolute  pathname  of  the  directory.  If  the 
argument  selected  by  argno  does  not  exist,  the  pathname 
of  the  working  directory  will  be  returned.  If  the  ar- 
gument was  bad  (in  case  of  a nonzero  status  code  be- 
low), the  argument  itself,  or  the  resulting  pathname, 
is  returned.  (Output) 

is  a standard  status  code.  It  will  be  zero  if  there 
was  no  argument  or  if  the  argument  was  the  name  of  a 
valid  directory.  If  nonzero,  the  argument  did  not 
point  to  a directory  that  exists.  (Output) 


1)  argno 

2)  dirpath 

3)  code 
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Wame : goto_seg_ 


Subroutine 


This  subroutine  merely  transfers  to  a location,  given  a pointer. 
It  can  be  used  to  transfer  control  to  another  subroutine  by  using  a 
transfer  instruction  instead  of  a call  (callsp  or  call6)  instruction. 

Usage 


ieclare  goto_seg_  entry  (bit(36)  aligned,  ptr); 
call  goto_seg_  (word,  entryptr); 

1)  word  is  a word  of  data  to  be  passed  as  an  argument  to  the  pro- 

cedure being  called.  (Input/Output) 

2)  entryptr  is  a pointer  to  the  entry  point  to  be  called.  When  the 

subroutine  invoked  by  the  transfer  to  entryptr  returns, 
return  will  be  directly  to  the  statement  after  this  call 
to  goto_seg_  (i.e.,  the  effect  will  be  the  same  as  if  the 
entryptr  had  been  called  directly.)  The  goto_seg_  subrou- 
tine has  no  stack  frame  of  its  own,  so  calls  to  it  will  be 
transparent.  (Input) 
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Subroutine 

Marne : line_number_inserter 

This  command  is  used  to  "patch"  certain  lines  in  the  source  of 
tne  programs  try_dir_reference_.pl 1 and  test_dir_auth.pl 1 , so  that  er- 
ror conditions  can  be  properly  reported  by  these  procedures  when  they 
are  executed.  Within  these  programs,  tnere  are  calls  to  various  error 
handling  subroutines,  and  the  first  argument  to  these  subroutines  is 
the  source  line  number  from  which  the  call  was  made.  The  error  han- 
dling routines  can  then  report  the  line  number  to  the  user  as  an  aid 
in  locating-  the  cause  of  the  error  in  the  source  program.  Since  PL/I 
provides  no  facility  for  passing  the  line  number  as  an  argument  auto- 
matically, these  line  numbers  must  be  passed  as  constants.  The 
line_number_inserter  is  run  on  try_dir_reference_.pl 1 and 
test_dir_auth.pl 1 to  insert  the  proper  line  numbers  each  time  these 
programs  are  changed . 

Usage 

,ine_number_inserter  path 

1)  path  is  the  pathname  of  the  source  program  to  be  patched. 

This  should  be  try_dir_reference_.pl1  or 
test_dir_auth.pl 1 , or  may  be  any  other  PL/I  source  pro- 
grams to  be  patched  in  the  manner  described  in  Notes 
below.  The  updated  source  replaces  the  original. 

Motes 

Tnis  command  searches  through  the  segment  specified  for  an  exact 
match  with  any  of  the  following  strings: 

"call  check_status_  (" 

"call  set_acl_test  (" 

"call  set_saved_loc  (" 

"call  list_acl_test  (" 

’■in.'s  exactly  as  above  will  be  considered  a match  — more  or 
i 3 between  the  words  will  cause  the  match  to  fail. 

■’"uracters  following  each  matching  string  in  the  origi- 
•rmcnt  must  form  an  integer  constant  (leading  blanks  Der- 
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line  number  inserter 


mitted  within  the  four  character  field)  and  the  character  after  the 
integer  must  be  a comma.  If  this  is  the  case,  the  existing  integer 
constant  is  replaced  by  another  constant  equal  to  the  line  number  of 
tnat  statement  within  the  segment. 

An  error  will  be  detected  if  a match  is  found  but  the  integer  and 
comma  do  not  follow  as  required.  If  an  error  occurs,  the  source  will 
have  been  modified  up  to  that  line. 

Example 

Assume  line  245  in  the  source  program  appeared  as  follows: 

/*  Example  */  call  set_saved_loc  ( 1,  "DSC-13"); 

After  running  line_number_inserter , the  line  will  be  changed  to  the 
following : 


/#  Example  */  call  set_saved_loc  ( 245,  "DSC-13"); 

ilote  that  the  field  width  allows  up  to  9999  lines  in  the  source  seg- 
ment. 
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mbx  test.ec 


Exec  com 


Name : mbx_test.ec 

This  exec_com  performs  the  message  segment  tests  of  the  access 
isolation  mechanism  utilizing  the  mail  command.  It  new_procs  itself 
to  various  authorizations  while  sending  messages  to  the  user's  mail- 
box. Then,  at  a fixed  authorization,  it  attempts  to  read  the  mes- 
sages. Tne  user  then  can  determine  whether  the  expected  messages  ap- 
pear. In  order  to  use  this  exec_com,  the  user  must  place  a call  to 
rabx_test_start_up.ec  in  his  start_up.ec  to  be  executed  at  new_proc 
t ime . 


Usage 


:xec_com  mbx_test  classl  class2  class3  class4  class5  classG 

1)  classi.  are  six  authorizations  that  the  user  is  allowed  to 

new_proc  to.  These  six  authorizations  must  have  a spe- 
cific relationship  to  each  other  which  is  the  same  as 
those  for  create_test_dir.ec.  The  authorization  class3 
may  be  any  authorization  above  system_low  that  contains 
at  least  two  categories. 

Notes 


After  validating  the  arguments,  the  user  will  be  asked  whether  he 
wishes  to  delete  his  old  mailbox.  The  mailbox  will  not  be  deleted  if 
it  contains  mail.  Then,  several  temporary  driving  segments  are  creat- 
ed in  the  home  directory  in  a manner  similar  to  create_test_dir.ec, 
and  the  new_proc  to  the  six  authorizations  begins.  From  that  point 
on,  the  operation  of  the  command  is  self  explanatory. 


180 


mbx_test_start_up.ec 


mbx_test_start_up.ec 


Exec  com 


Name : mbx_test_start_up.ec 

This  exec_com  is  called  at  each  new_proc  performed  by 
mbx_test.ec.  Its  operation  is  very  similar  to  the  exec_com 
create_test_start_up.ec.  The  difference  is  that,  instead  of  creating 
directories  or  segments  at  each  new_proc,  this  exec_com  sends  a mes- 
sage to  the  user's  mailbox. 

Usage 


exec_com  mbx_test_start_up 


Notes 


See  the  writeup  of  create_test_start_up.ec. 
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new_proc 


Subroutine 

Marne : new_proc_ 

fne  new_proc_  subroutine  creates  a new  process  with  possibly  a 
new  access  authorization. 

Usage 

declare  new_proc_  entry  (bit(72)  aligned,  fixed  bin( 35) ) ; 
call  new_proc_  (new_auth,  code); 

1)  new_auth  is  the  internal  form  of  a standard  Multics  access  au- 

thorization. (Input) 

2)  cede  is  a standard  system  status  code.  (Output) 

Motes 

The  only  way  that  one  will  return  from  this  subroutine  is  when  an 
error  has  occurred  in  its  execution.  That  error  will  be  be  returned 
in  "code". 
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Command 

Name : new_proc_test 

This  command  operates  just  like  the  Multics  new_proc  command,  ex- 
cept that  no  checks  are  made  for  a valid  -authorization  argument. 

Thus,  a new_proc  will  always  take  place,  and  any  errors  in  the  author- 
ization argument  should  be  detected  by  the  answering  service.  See  the 
MPM  writeup  of  new_proc  for  description  of  the  arguments. 
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number 


Subroutine 


Name : number_ 

This  function  returns  the  character  string  representation  of  tne 
decimal  value  of  binary  integer.  It  is  exactly  like  the  char  builtin 
function  of  PL/I,  except  that  the  string  returned  has  leading  blanks 
stripped . 

Usage 


declare  number_  entry  (fixed  bin)  returns  (char(*)); 
charstring  = number_  (n); 

1)  n is  the  number  to  be  represented  as  a character  string. 

( Input) 

2)  charstring  is  the  character  string  representation  of  the  number  in 

decimal.  The  length  of  this  string  will  be  the  minimum 
number  of  characters  necessary  to  represent  the  number, 
i.e.,  there  will  be  no  blanks  in  this  string. 
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Subroutine 


Name : print_acl 


The  print_acl  subroutine,  given  a segment  Access  Control  List 
(ACL),  will  print  it  out  on  "user_output" . There  will  be  normal  ACL 
ordering  and  everything  will  appear  left-justified  as  illustrated  by 
the  following  example: 

rew  Jones. Sys.* 

e Smith.*.* 

rw  * . SysDaemon.* 

null  *.Beta.* 

Usage 

del  print_acl  entry  (1  (*)  aligned,  2 char(32),  2 bit( 36) , 2 
bit(36),  2 fixed  bin(35),  fixed  bin(35)); 


call  print_acl  (acl,  code); 


1)  acl 

2)  code 


is  a segment_acl  structure.  See  Notes  below.  (Input? 
is  a standard  status  code.  See  Notes  below.  (Output) 


Notes 


The  following  structure  is  used: 

del  1 segment_acl  (*)  aligned, 

2 group_id  char (32), 

2 modes  bit( 36) , 

2 zero_pad  bit(36), 

2 status_code  fixed  bin(35); 


1)  group_id  is  the  group  identifier  (in  the  form 

person.project .tag  ) which  identifies  the  processes 
to  which  this  acl  entry  applies. 


2)  modes 


contains  the  access  modes  for  this  group  identifier. 
The  first  three  bits  correspond  to  the  access  modes 
read,  execute,  write.  The  remaining  bits  must  be 
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print_acl 


3)  zero_pad  must  contain  zero.  (This  field  is  used  for  extended 

access) 

U)  status_code  is  a standard  status  code  for  only  this  entry. 

Certain  errors  are  looked  for  in  the  input  segment  ACL.  If 
found,  a nonzero  code  will  be  returned  and  the  ACL  will  not  print  out 
on  "user_output" . The  two  errors  that  are  looked  for  and  returned  in 
code  when  detected  are  the  errors  "empty_acl",  and  "bad_acl_mode" . No 
attempt  is  made  to  detect  the  possible  ACL  error  "bad_name",  and  thus 
bad  group_ids  will  print  out  when  input  to  print_acl. 
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Subroutine 


Name : process_1_proc 


The  process_1_proc  subroutine  is  called  by  the  test_seg_acl  com- 
mand when  invoked  from  the  first  terminal.  (See  the  writeup  of  the 
test  seg  acl  command.)  It  does  the  following: 

1)  Creates  the  temporary  directory  test_seg_acl_workspace_dir 
in  the  process  directory  of  ul. 

2)  Creates  the  temporary  segment  test  seg  acl_mailbox  in  the 
directory  >udd>p1>u1. 

3)  Places  IPC  information  in  the  segment  test_seg_acl_mailbox. 

4)  Directs  ul  to  go  to  a terminal  t2  and  issue  the  second  form 
of  the  test_seg_acl  command. 

5)  Waits  for  the  second  form  of  the  test_seg_acl  command  to 
fill  the  segment  test_seg_acl_mailbox  with  IPC  information. 

6)  Activates  five  modules,  which  test  the  basic  access  control 
mechanism. 

7)  Upon  completion,  cleans  up  temporary  work  space  and  causes 
the  termination  of  the  second  form  of  the  test_seg_acl  com- 
mand. 

Usage 


declare  process_1_proc  entry  (label); 

call  process_1_proc  (abandon_test_seg_acl) ; 

1)  abandon  test  seg_acl  is  the  label  constant  affixed  to  the  state- 
ment terminating  the  test  segacl  command. 

( Input) 
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Subroutine 

Name : process_2_proc 

The  process_2 _proc  subroutine  is  called  by  the  test_seg_acl  com- 
mand when  invoked  from  the  second  terminal.  (See  the  writeup  of  the 
test_seg_acl  command.)  It  does  the  following: 

1)  Fills  the  segment  >udd>p1>u1>test_seg_acl_mailbox  with  IPC 
information . 

2)  Waits  for  instructions  from  process  PI  to  make  various  ac- 
cess attempts  on  the  segment  try_me . 

3)  Communicates  the  results  of  the  above  access  attempts  back 
to  PI. 

4)  Upon  termination,  cleans  up  any  temporary  work  area. 

Usage 

declare  process_2_proc  entry  (label,  char(»),  char(*)); 
call  process_2_proc  (abandon  test  seg  acl.  ul,  pi); 

1)  abandon  test  seg  acl  is  the  label  constant  affixed  to  the  state- 

ment terminating  the  test_seg_acl  command.  (Input) 

2)  ul  is  the  Multics  user  name.  See  writeup  of  the 

test  seg  acl  command.  (Input) 

3)  pi  is  the  Multics  project  id.  (Input) 
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Active  function 


Name : quota 

This  active  function  returns  the  quota  of  a directory. 


Usage 


[quota  path] 


1 ) path 


is  the  pathname  of  a directory. 


quota_used  quota_used 

Active  Function 

Name : quota_used 

This  active  function  returns  the  quota  used  of  a directory. 

asage 

[quota_used  path] 

1)  path  is  the  pathname  of  a directory. 
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Command 


Names : read_tape_test,  write_tape_test 

These  commands  are  identical  to  the  system  read_tape  and 
write_tape  commands,  except  that  no  check  is  made  to  see  if  the  user 
has  the  proper  access  to  the  segment  specified,  or  if  the  segment  is 
not  found.  The  request  is  always  queued. 
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Subroutine 


Name : response_to_start_up 

The  response_to_start_up  subroutine  is  called  by  the  test_ipc 
command  from  the  first  terminal.  It  does  the  following: 

1)  Initiates  the  temporary  segment  "multi_process_info" . (See 
the  writeup  of  the  test_ipc  command.) 

2)  Determines  the  correct  IPC  message  to  send  to  the  process 
using  the  second  terminal.  Determines  the  authorization  of 
the  "next"  process  to  new_proc  to. 

3)  Sends  the  message  to  the  process  using  the  second  terminal. 
New_procs  to  a process  with  correct  "next"  authorization. 


Usage 

declare  response_to_start_up  entry; 
call  response_to_start_up; 
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Active  Function 

Name : short_string 

This  active  function  returns  the  short  form  of  an  authorization 
string . 

Usage 

[ short_string  auth_string] 

1)  auth_string  is  an  authorization  string.  It  must  be  enclosed  in 
quotes  if  it  contains  any  blanks. 

Notes 

Note  that  a null  string  may  be  returned  for  unnamed  authoriza- 
tions, such  as  system_low. 

If  the  auth_string  is  invalid,  the  string  "**"  is  returned. 
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Subroutine 

Name:  terminal_2_proc 

The  terminal_2_proc  subroutine  is  called  by  the  test_ipc  command 
from  the  second  terminal.  It  does  the  following: 

1)  Creates  an  event  wait  channel. 

2)  Outputs  on  "user_output"  its  process_id  and  the  id  of  the 
event  wait  channel  it  created. 

3)  Looks  for  messages  sent  from  the  processes  using  the  first 
terminal.  (See  the  writeup  of  the  test_ipc  command.)  Any 
messages  that  are  received  but  should  not  be  are  noted  with 
an  error  message  on  "user_output" . 

Usage 

declare  terminal_2_proc  entry; 
call  terminal_2_proc ; 


j 

! 
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Subroutine 


Name : test  acl  use 


The  test_acl_use  subroutine  is  called  by  the  process_1_proc  sub- 
routine to  test  that  the  ACL  of  the  segment  try_me  restricts  correctly 
the  access  of  process  P 2 to  try_me.  (See  the  writeup  of  the 
tes^seg^acl  command.)  It  uses  the  hcs_$append_branch , 
hcs_$add_acl_entries,  hcs_$delete_acl_entries , and  hcs_$replace_acl 
subroutines  in  making  a series  of  alterations  on  the  ACL  of  try_me . 
After  each  alteration,  it  instructs  P2  on  t2  to  access  try_me.  It 
verifies  that  the  P2  access  to  try_me  was  restricted  in  accordance 
with  the  current  ACL  of  try_me. 

Usage 

declare  test_acl_use  entry  (char(#),  char(*),  1,  2 bit(36) 

aligned,  2 char  (168)  aligned,  2,  3 fixed  bin(71),  3 
fixed  bin(71),  3 bit(36),  2,  3 fixed  bin(71),  3 fixed 
bin(71),  3 bit(3&),  2 char(32),  2,  3 fixed  bin(35),  3 
char(32),  3 bit(36),  3 bit(36),  ptr,  1,  2 fixed  bin, 

2 (1)  fixed  bin(71),  fixed  bin ( 35 ) ) ; 

call  test_acl_use  (ul,  pi,  mailbox,  wait_list,  code); 


1)  ul 


is  the  Multics  user  name.  See  the  writeup  of  the 
test_seg^_acl  command  and  process_1_proc  subroutine. 
( Input) 


2)  pi 


is  the  Multics  project  id.  (Input) 


3)  mailbox  is  the  content  of  the  IPC  mailbox  which  resides  in 

the  temporary  segment 

>udd>p1>u1>test  seg_acl_ mailbox.  ( Input) 


4)  wait  list 


is  the  one  element  list  of  event  wait  channels  for 
process  PI . ( Input) 


5)  code 


is  a status  code.  See  Notes  below.  (Output) 


Notes 


The  value  returned  in  code  above  is  either  zero  or  non-zero.  If 
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zero  is  returned,  then  no  errors  were  encountered  in  the  test  that  the 
ACL  of  a segment  restricts  access  correctly  to  that  segment.  If  non- 
zero, then  some  sort  of  error  occurred  and  was  noted  on  the  stream 
"user_output" . 
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test  add  list 


Subroutine 


Name : test  add  list 


The  test_add_list  subroutine  is  called  by  the  process_1_proc  sub- 
routine to  test  the  mutual  consistency  of  the  hcs_$add_acl_entries  and 
hcs_$list_acl  subroutines.  It  calls  the  hcs_$add_acl_entries  subrou- 
tine a series  of  times,  each  time  attempting  to  add  certain  ACL  en- 
tries to  the  ACL  of  the  segment  add_list.  After  each  add  attempt,  it 
calls  the  hcs_$list_acl  subroutine  and  compares  the  listed  ACL  with 
the  ACL  expected  after  the  add  attempt. 

Usage 

declare  test_add_list  entry  (char(*),  char(*),  char(*)  aligned, 
fixed  bin(35)); 

call  test_add_list  (ul,  pi,  path_name,  code); 


1)  ul 


is  the  Multics  user  name.  See  the  writeup  of  the 
test_seg_acl  command  and  the  process_1_proc  subrou- 
tine. (Input) 


2)  pi 


is  the  Multics  project  id.  (Input) 


3)  path_name  is  the  Multics  path  name  for  the  temporary  directory 
test  seg  acl  workspace  dir.  ( Input) 


4)  code 


is  a status  code.  See  Notes  below.  (Output) 


Notes 


The  value  returned  in  code  above  is  either  zero  or  nonzero.  If 
zero  is  returned,  then  no  errors  were  encountered  in  the  test  of  the 
mutual  consistency  of  the  hcs_$add_acl_entries  and  hcs_$list_acl  sub- 
routines. If  nonzero,  then  some  sort  of  error  occurred  and  was  noted 
on  the  stream  "user_output" . 
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Subroutine 


Name : test_append_list 

The  test_append_list  subroutine  is  called  by  the  process_1_proc 
subroutine  to  test  the  mutual  consistency  of  the  hcs_$append_branch 
and  hcs_$list_acl  subroutines.  It  creates  the  segments  append_list_1 , 
append_list_2,  append_list_3,  and  append_list_4  in  the  temporary  di- 
rectory test_seg_acl_workspace_dir . After  the  creation  of  each  seg- 
ment, it  calls  the  hcs_$list_acl  subroutine  and  compares  the  listed 
ACL  with  the  ACL  expected  after  the  call  to  hcs_$append_branch . 


Usage 

declare  test_append_list  entry  (char(*),  char(*),  char(*)  aligned, 
fixed  bin(35)); 

call  test_append_list  (ul,  pi,  path_name,  code); 


1)  ul 


2)  pi 


3)  path_name 

4)  code 


is  the  Multics  user  name.  See  the  writeups  of  the 
test_seg_acl  command  and  the  process_1_proc  subrou- 
tine. (Input) 

is  the  Multics  project  id.  Again,  see  the  writeups 
of  the  test_seg_acl  command  and  process_1_proc  sub- 
routine. (Input) 

is  the  Multics  path  name  for  the  temporary  directory 
test  seg  acl  workspace  dir.  ( Input) 

is  a status  code.  See  Notes  below.  (Output) 


Notes 


1 


The  value  returned  in  code  above  is  either  zero  or  nonzero.  If 
zero  is  returned,  then  no  errors  were  encountered  in  the  test  of  the 
mutual  consistency  of  the  hcs_$append_ branch  and  hcs_$list_ acl  subrou- 
tines. If  nonzero,  then  some  sort  of  error  occurred  and  was  noted  on 
the  stream  "userjoutput" . 
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Subroutine 


Name:  test_delete_list 

The  test_delete_list  subroutine  is  called  by  the  process_1_proc 
subroutine  to  test  the  mutual  consistency  of  the 

hcs_$delete_acl_entries  and  hcs_$list_acl  subroutines.  It  first  uses 
the  hcs_$add_acl_entries  subroutine  to  construct  a sizeable  ACL  for 
the  segment  delete_list.  It  then  calls  the  hcs_$delete_acl_entries 
subroutine  a series  of  times,  each  time  attempting  from  delete  certain 
ACL  entries  from  the  ACL  of  the  segment  delete_list.  After  each  de- 
lete attempt,  it  calls  the  hcs_$list_acl  subroutine  and  compares  the 
listed  ACL  with  the  ACL  expected  after  the  deletion  attempt. 

Usage 

declare  test_delete_list  entry  (char(*),  char(*),  char(*)  aligned, 
fixed  bin ( 35) ) ; 

call  test_delete_list  (ul,  pi,  path_name,  code); 

is  the  Multics  user  name.  See  the  writeup  of  the 
test_seg_acl  command  and  the  process_1_proc  subrou- 
tine. (Input) 

is  the  Multics  project  id.  (Input) 

is  the  Multics  path  name  for  the  temporary  directory 
test_seg_acl_workspace_dir . ( Input) 

is  a status  code.  See  Notes  below.  (Output) 

Notes 


1)  ul 

2)  pi 

3)  path_name 

4)  code 


The  value  returned  in  code  above  is  either  zero  or  nonzero.  If 
zero  is  returned,  then  no  errors  were  encountered  in  the  test  of  the 
mutual  consistency  of  the  hcs_$delete_acl_entries  and  hcs_$list_acl 
subroutines.  If  nonzero,  then  some  sort  of  error  occurred  and  was 
noted  on  the  stream  "user_output" . 


a 
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Command 


Name : test_dir_auth,  tda 

nis  command  utilizes  a special  test  directory  to  check  that  the 
access  isolation  controls  work  properly  with  respect  to  directories. 

In  order  to  use  this  command  properly,  the  special  test  directory  must 
first  be  created  using  the  exeo_com  "create_test_dir . ec"  . 


test_di  r_auth  -dirname- 

1)  dirname  is  the  pathname  of  the  special  test  directory  described 

below.  If  missing,  the  working  directory  is  used. 


Notes 


The  authorization  of  the  process  calling  this  command  must  be  a 
certain  level  and  category  set  combination  as  specified  in  the  writeup 
to  create_test_dir.ec.  The  user  does  not  need  system  privilege  to  run 
this  command  --  in  fact,  he  probably  shouldn't  have  it  if  the  controls 
are  to  be  tested  properly. 

If  the  test  succeeds,  no  error  messages  will  be  printed.  If  the 
test  fails,  a message  will  be  printed  indicating  the  reason  for  the 
failure  (bad  status  code  or  condition),  the  expected  status  code  or 
condition,  and  the  directory  or  segment  that  was  being  referenced  when 
the  error  occurred.  The  access  class  of  the  segment  can  be  determined 
from  the  segment's  or  directory's  pathname  (see  the  writeup  of 
create_test_dir .ec) . A comprehensive  discussion  of  most  of  the  error 
messages  that  can  be  produced  may  be  found  in  the  writeup  of 
check_status_.  There  are,  however,  additional  errors  that  may  turn  up 
that  will  produce  messages  not  discussed  in  that  writeup. 
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Command 

Name : test_ipc,  tipc 

Tne  test_ipc  command  tests  that  the  interprocess  communication 
(IPC)  facility  of  Multics  is  working  correctly  with  respect  to  the  ac- 
cess isolation  mechanism.  The  command  must  be  issued  twice,  once  from 
each  of  two  terminals,  and  then  repeatedly  at  each  new_proc  on  the 
first  terminal.  The  different  invocations  of  the  command  are  distin- 
guished by  the  number  of  arguments. 

Usage  (from  first  terminal) 

test_ipc  authl  auth2  auth3  auth4  auth5  auth6 

1)  authi  are  the  names  of  six  Multics  access  authorizations  as 

specified  in  Notes  below.  The  user  must  be  able  to 
new__proc  to  a process  having  any  one  of  these  author- 
izations . 

Usage  (from  second  terminal) 
test_i pc 

Usage  (from  first  terminal,  at  each  new_proc) 
test_ipc  -go 


1 


Notes 

The  command  is  called  at  the  first  terminal  to  begin  the  test  of 
IPC.  The  user  must  be  logged  in  at  "system_low" . For  later  refer- 
ence, the  terminal  from  which  this  command  is  issued  is  known  as  "tl". 


The  six  authi  arguments  are  six  Multics  authorizations  whose  lev- 
el numbers  and  category  sets  are  related  as  follows: 


level  (auth3) 

level  (authl) 
level  (auth2) 
level  (authU) 


= any  level  not  equal  to  ”system__low" 
or  "system_high" 

< level  (auth3) 

= level  (auth3) 

= level  (auth3) 
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test_ipc 


level  (auth5)  > level  (auth3) 
level  (auth6)  : level  (auth3) 


cat  (auth.3) 

cat  (authl) 
cat  (auth2) 
cat  (auth3) 
cat  (auth5) 
cat  (auth6) 


any  category  set  having 
at  least  two  components 
cat  (auth3) 

a proper  subset  of  cat  (auth3) 
a proper  subset  of  cat  (autn4) 
cat  (auth3) 

a category  set  isolated  from  cat  (auth3) 


Jpon  receiving  instructions  to  do  so,  the  user  must  then  call 
test_ipc  from  a second  terminal  without  arguments.  This  second  termi- 
nal is  known  as  "t2".  The  user  must  login  at  this  terminal  at  an  au- 
thorisation equal  to  auth3  above.  It  is  not  important  whether  he  uses 
the  s .me  or  different  name  and  project  as  used  on  the  first  terminal 
(although  a system  parameter  may  be  set  that  does  not  allow  multiple 
logins  by  the  same  user). 


After  ths  user  calls  the  command  from  t2,  oest_ipc  performs  sev- 
eral new_procs  at  tl.  After  each  new_proc,  the  user  must  continue  the 
operation  of  the  command  by  calling  test_ipc  with  the  argument  -go. 

It  is  recommended  that  the  user's  start_up.ec  be  modified  for  the  test 
to  call  this  command  automatically  at  new_proc.  The  call  should  have 
no  effect  unless  test_ipc  was  called  in  the  previous  process. 

For  each  new_proc  on  tl,  a message  is  sent  to  the  process  at  t2 
using  the  IPC  facility.  Beginning  at  system_low,  the  first  new_proc 
creates  a process  with  authorization  equal  to  authl.  The  second 
new_proc  creates  a process  with  authorization  equal  to  auth2.  This 
continues  until  a last  new_proc  destroys  a process  with  authorization 
equal  to  auth6,  and  creates  a final  process  with  authorization  equal 
to  "system_low" . 

The  test_ipc  command  called  from  t2  looks  for  the  message  sent  by 
the  process  at  tl.  If  it  receives  one  sent  from  a tl  process  having 
authorization  auth4,  auth5,  or  auth6,  its  prints  an  error  on  t2.  If 
no  violations  are  detected,  ready  messages  will  print  out  on  both  ter- 
minals upon  command  termination.  Note  that  all  error  messages  con- 
cerning access  violations  appear  on  t2. 
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Subroutine 


Name : test_replace_li st 

The  test_replace_list  subroutine  is  called  by  the  process_l_proc 
subroitine  to  test  the  mutual  consistency  of  the  hcs_$replace_acl  and 
hcs_? j.ist_acl  subroutines.  It  calls  the  hcs_$replace_acl  subroutine  a 
series  of  times,  each  time  attempting  to  replace  the  ACL  of  the  seg- 
ment replace_li st . After  each  replacement  attempt,  it  calls  the 
hcs_$list_acl  subroutine  and  compares  the  listed  ACL  with  the  ACL  ex- 
pected after  the  replacement  attempt. 


Usage 

declare  test_replace_list  entry  (char(*),  char(*),  char(*) 
aligned,  fixed  bin (35)); 

call  test_replace_list  ( u 1 , pi,  path_name,  code); 


1 ) u 1 


2)  pi 


is  the  Multics  user  name.  See  the  writeup  of  the 
test  seg  acl  command  and  the  process_l_proc  subrou- 
tine. (Input) 

is  the  Multics  project  id.  (Input) 


3)  pat'n_name  is  the  Multics  path  name  for  the  temporary  directory 
test_seg_acl_workspace_dir . ( Input) 


4)  code 


is  a success  code.  See  Notes  below.  (Output) 


Notes 


The  value  returned  in  code  above  is  either  zero  or  nonzero.  If 
zero  is  returned , then  no  errors  were  encountered  in  the  test  of  the 
mutual  consistency  of  the  hcs_$replace_acl  and  hcs_$list_acl  subrou- 
tines. If  nonzero,  then  some  sort  of  error  occurred  and  was  noted  on 
the  stream  "user_output” . 
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Command 


Name:  test_seg_acl 

This  command  tests  the  basic  access  control  mechanism  of  Multics 
by  executing  a series  of  tests  to  ascertain  first,  that  the 
hcs_$append_branch , hcs_$add_acl_entries , hcs_$delete_acl_entries , 
hcs_$list_acl , and  hcs_$replace_acl  subroutines  function  correctly, 
and  second  that  the  ACL  of  a segment  correctly  controls  the  access  of 
a process  to  that  segment.  The  command  must  be  issued  twice,  once 
from  each  of  two  terminals  by  different  users.  The  two  usages  are 
distinguished  by  appearance  of  the  arguments. 

Usage  (from  first  terminal) 

t es  t_s  eg_a  c 1 

Usage  (from  second  terminal) 
test  seg  acl  ul  pi 


1) 

ul 

is  the  name 
Notes  below 

of 

the 

user  at 

the 

first  terminal, 

, See 

2) 

pi 

is  the  name 
terminal . 

of 

the 

project 

of 

the  user  at  the 

first 

Notes 

The  tes^seg^acl  command  is  issued  at  the  first  terminal  to  begin 
the  test  of  the  basic  access  control  mechanism.  For  later  reference, 
this  user's  process  is  referred  to  as  pi  and  his  terminal  as  tl. 

When  test_seg_acl  is  called  rom  the  first  terminal,  five  main 
modules  are  referenced:  test_append_list , test_add_list , 

test_delete _li st , test_replace_list,  and  test_acl_use . The  command 
creates  the  segments  append_list_1 , append_list_2,  append_list_3 , 
append_list_4 , add_list,  delete_list,  replace_list , and  try_me  in  a 
temporary  directory  in  the  process  directory  of  PI.  It  creates  also  a 
temporary  segment,  test  seg  acl  mailbox,  in  the  directory  >udd>p1>u1. 
The  following  table  lists  the  modules  called,  the  temporary  segments 
referenced,  and  the  function  of  each  module.  This  information  is 
helpful  in  diagnosing  any  errors  that  might  be  reported. 
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Module 


Using 


Purpose 


test_append_list 

append_list_1 
appe  nd_list_2 
append_list_3 
append_list_4 

Test  the  mutual  consis- 
tency of  the  subroutines 
hcs_$append_branoh  and 
hcs_$list_acl . 

test_add_list 

add_list 

Test  the  mutual  consis- 
tency of  the  subroutines 
hcs_$add_acl_entries  and 
hcs_$list_acl . 

test_delete_list 

delete_list 

Test  the  mutual  consis- 
tency of  the  subroutines 
hcs_$delete_acl_entries 
and  hcs_$list_acl . 

test_replace_list 

replace_list 

Test  the  mutual  consis- 
tency of  the  subroutines 
hcs_$replace_acl  and 
hcs_$list_acl . 

test_acl_use 

try_me 

Test  that  the  ACL  of 
try_me  does  in  fact 
control  the  access  of 
process  P2  (See  Notes 
following  ) to  try_me. 

After  calling  tes^seg^acl  from  the  first  terminal,  instructions 
are  printed  telling  the  user  to  login  at  a second  terminal  under  a 
different  user  and/or  project  id.  This  second  user  is  referred  to  as 
"u2",  his  project  id  as  "p2" , his  process  as  "P2",  and  the  second  ter- 
minal as  "t2". 

Process  P2  receives  instructions  from  PI  to  access  the  segment, 
try_me.  It  returns  the  results  of  its  access  attempts  to  PI. 

If  the  test  seg  acl  command  encounters  any  error  in  the  basic  ac- 
cess control  mechanism,  the  error  is  noted  on  tl  and  ready  messages 
appear  on  both  terminals.  If  no  errors  occur,  then  ready  messages 
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test_seg_acl 


simply  appear  on  both  terminals  upon  command  termination, 


Certain  errors  print  out  on  tl  in  coded  form.  That  basic  form 


ts_acl:  -system_status_code- 

Segment  = "pathname" 

Error  number  = "number" 

-Optional  information- 

The  following  tables  give  the  details  for  these  coded  error  messages. 
A dash  indicates  the  absence  of  optional  information.  It  should  be 
noted  that  the  sequence  of  error  messages  in  these  tables  correspond 
to  the  actual  sequence  of  tests  being  made  in  a particular  test  mod- 


Segment 


Error  Optional  Situation 

number  information 


append_list_i  1 


Could  not  create 
segment  giving  PI 
rw  access. 


Expected  ACL  Could  not  list  ACL 
of  segment. 

Listed  ACL  ACL  incorrectly 
Expected  ACL  listed. 


add  list 


Could  not  create 
segment  giving  PI 
rw  access. 


Could  not  create  a 
project  name  different 
from  pi . 
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Segment 


Error 

number 

Optional 

information 

Situation 

20 

- 

Added  to  ACL: 
ul ,p2.*  r 

a.b.c.d  rew 

o 

m 

- 

No  flag  on: 
a.b.c.d  rew 

40 

Expected  ACL 

Could  not  list  ACL 
of  segment. 

50 

Listed  ACL 
Expected  ACL 

ACL  incorrectly 
listed 

60 

- 

Could  not  add  to  ACL 
u 1 . p2 . * r 

70 

Expected  ACL 

Could  not  list  ACL 
of  segment. 

80 

Listed  ACL 
Expected  ACL 

ACL  incorrectly 
listed . 

90 

Could  not  change 
ACL  entry: 
u1.p2.*  r 

to : 

ul .p2.*  re 

100 

Expected  ACL 

Could  not  list  ACL 
of  segment. 

110 

Listed  ACL 
Expected  ACL 

ACL  incorrectly 
listed . 

120 

- 

Could  not  create  a 
user  name  different 
from  ul . 
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Segment 


delete  list 


test_seg_acl 


Error 

number 

Optional 

information 

Situation 

130 

- 

Could  not  add  to  ACL: 
u2 . p2 . * re 

140 

Expected  ACL 

Could  not  list  ACL 
of  segment. 

150 

Listed  ACL 
Expected  ACL 

ACL  incorrectly 
listed . 

160 

- 

Could  not  add  to  ACL: 
u2.p2.b  rew 

170 

Expected  ACL 

Could  not  list  ACL 
of  segment. 

180 

Listed  ACL 
Expected  ACL 

ACL  incorrectly 
listed . 

190 

Could  not  add  to  ACL 
*.p1.*  r 

u2 . * . * r 

ul.pl.*  rew 

* . * . * e 

200 

Expected  ACL 

Could  not  list  ACL 
of  segment. 

210 

Listed  ACL 
Expected  ACL 

ACL  incorrectly 
listed . 

1 

- 

Could  not  create 
segment,  giving  PI 
rw-access . 

10 

- 

Could  not  create  a 
user  name  different 
from  ul . 
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test_seg_acl 


Segment 


Error 

number 


Optional 

information 


Situation 


Could  not  create  a 
project  name  different 
from  p 1 . 

Could  not  create  a 
project  name  different 
from  pi  and  p2. 


Could  not  add  to  ACL: 
ul .pi .a  rew 

u2.p2.a  rew 

u2.p3.a  re 

* . p2 . * r 

Could  not  create  a 
user  name  different 
from  ul  and  u2. 

Deleted  from  ACL: 
ul .pi .* 
u2.p2.a 
u3.p4.» 

VSysDaemon.* 
a .b 

No  flag  on: 
a .b 


Expected  ACL  Could  not  list  ACL 
of  segment. 

Listed  ACL  ACL  incorrectly 
Expected  ACL  listed. 
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Segment 


replace_list 


test_seg_acl 


Error  Optional  Situation 

number  information 


100 


110 

120 

Expected 

ACL 

130 

Listed  ACL 
Expected  ACL 

1 

- 

10 

20 


30 


40  Expected  ACL 


Could  not  delete 
from  ACL: 
u 1 . p 1 . * 
u2.p2.a 
u3.p4.* 

* .SysDaemon.* 

Flag  on: 
u3.p4.» 

Could  not  list  ACL 
of  segment. 

ACL  incorrectly 
listed . 

Could  not  create 
segment,  giving  PI 
rw-access . 

Could  not  create  a 
user  name  different 
from  u 1 . 

Could  not  create  a 
project  name  different 
from  pi . 


Could  not  replace 
ACL  with: 


ul  .pi  .a 

re  w 

# . # * 

r 

*. SysDaemon.* 

rw 

u2 . p2 . * 

rw 

Could  not  list 

ACL 

'■'f  segment. 
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Segment 


try_me 


Error  Optional  Situation 

number  information 


50 

Listed  ACL 
Expected  ACL 

ACL  incorrectly 
listed . 

60 

Could  not  create 
a user  name  different 
from  ul  and  u2. 

70 

- 

Replaced  ACL  with: 
u3.*.»  r 

a . b . c . d rew 

80 

- 

No  flag  on: 
a . b . c . d rew 

90 

Expected  ACL 

Could  not  list  ACL 
of  segment. 

100 

Listed  ACL 
Expected  ACL 

ACL  incorrectly 
listed . 

1 10 

- 

Could  not  replace 
ACL  with  empty  ACL. 

120 

Could  not  list 
supposedly  empty  ACL 
of  segment. 

130 

Listed  ACL 

Listed  ACL  was  not 
empty. 

1 

“ 

Could  not  create 
segment,  giving  PI 
rew-access. 

10 

Could  not  create  a 
user  name  different 
from  ul  and  u2. 
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Segment 


Error  Optional  Situation 

number  information 


20 


30 


40 


50,90,130 

170,210,260 

310,360,410 

460,510,560 

710 


Could  not  create  a 
project  name  different 
from  pi  and  p2. 

Could  not  create  a 
tag  value  different 
from  * and  the  tag 
value  associated  with 
u2  being  logged  onto 
t2 . 


Could  not  add  to  ACL: 


u2 .p2.x 

rew 

u2.p3.a 

rew 

u3.p2.a 

rew 

u2.p2.a 

null 

u2 . p2 . * 

rew 

u2 . * .a 

rew 

u2 . * . * 

rew 

* .p2.a 

rew 

*.p2.» 

rew 

*.*.a 

rew 

rew 

Could  not  wake  P2 
to  have  it  access 
segment . 


60,100,140  - PI  could  not  go 

180,220,270  blocked. 

320,370,420 
470,520,570 
720 
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test  seg  acl 


Segment 


Error 

number 


Optional 

information 


Situation 


70,110 

150,190 

230,280 

330,330 

430,480 

530,580 

730 


Listed  ACL 
The  P2 
access  data 
(See  following 
text  and 
table. ) 


P2  reported  improper 
access  to  segment. 


Could  not 
entry: 
u2.p2.a 
to : 

u2.p2.a 

Could  not 
entry: 
u2.p2.a 
to : 

u2.p2.a 

Could  not 
entry: 
u2.p2.a 
to : 

u2.p2.a 


change  ACL 


change  ACL 


change  ACL 


Could  not 
entry : 
u2.p2.a 
to: 

u2.p2.a 

Could  not 
u2.p2.a 


change  ACL 


delete : 
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test_seg_acl 


Segment 


Error  Optional  Situation 

number  information 


250 

Could  not 
u2 . p2 . * 
to : 

u2  . p2 . * 

change : 

rew 

r 

290 

- 

Could  not 
u2.p2.» 

delete : 

300 

Could  not 
u2 . * .a 
to : 

u2 . * .a 

change : 

rew 

r 

340 

- 

Could  not 
u2.#  .a 

delete : 

350 

Could  not 
u2 . * . * 
to : 

u2 . * . * 

change : 

rew 

r 

390 

- 

Could  not 
u2.».» 

delete : 

400 

Could  not 
*.p2.a 
to : 

* .p2.a 

change : 

rew 

r 

440 

- 

Could  not 
*.p2.a 

delete : 

450 

Could  not 

*.p2.« 

to: 

*.p2.» 

change : 

rew 

r 
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test  3eg  acl 


Segment 


Error  Optional  Situation 

number  information 


490 

— 

Could  not 
*.p2.« 

delete : 

500 

_ 

Could  not 

change: 

* .*  .a 

rew 

to : 
*.*.a 

r 

540 

- 

Could  not 
*.*.a 

delete: 

550 

Could  not 

change : 

* . * . * 

rew 

to: 

r 

700 

- 

Could  not 
with: 

replace  ACL 

u2 ,p2.x 

rew 

u2 , p3 • a 

rew 

u3  .p2.a 

rew 

ul  .pi .a 

rew 

When  process  P2  reports  improper  access  to  the  segment  try_me, 
then  the  optional  information  in  the  above  error  message  is  further 
coded  as : 


Error  on  other  terminal  = "number" 

Where  status _code  = "system_status_code" 
condition_found  = "condition_name" 
word_read  = "string" 
result_of_execution  = "string" 
ptr_try_me  = "ptr" 

This  information  gives  the  reason  for  P2  reporting  improper  access  to 
the  segment  try_me,  which  is  the  following  ALM  program: 
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test_seg_acl 


" Word  0 is  a constant  that  is  used  to  check  on  read 

" access. 

" Word  1 is  open  to  check  for  write  access. 

" Word  2 is  the  entry  point  to  check  execute  access. 

c:  oct  252525252525  in  word  0 

oct  0 in  word  1 

Ida  c in  word  2 

sta  ap',2,* 
short_return 
end 

The  following  table  details  this  optional  information  coding. 

Error  on  other  terminal  Meaning 


P2  was  able  to  initiate  the 
segment  try_ne,  and  perhaps 
read  it.  (See  value  in  status_code, 
word_read,  or  ptr_try_me.) 

P2  was  not  able  to  read  the 
segment  try_me . (See  value  in 
status_code,  condition_found , 
word_read,  or  ptr_try_me.) 

P2  did  not  encounter  the  condition 
"no_execute_permission"  when 
attempting  to  execute  try_me. 

(See  value  in  status_code, 
condi tion_found,  or 
result_of_execution. ) 

P2  did  not  encounter  the  condition 
"no_write_permission"  when 
attempting  to  write  into  try_me . 
(See  value  in  status_code,  or 
condition  found.) 


1000 


2000 


2100 


2200 
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Error  on  other  terminal  Meaning 




2300 


3000 


3100 


3200 


3300 

i 

I 

j 

4000 


4100 


P2  did  meet  "no_write_permission" , 
but  nevertheless  damaged 
word  1 of  try_me.  (See 
value  in  word_read,  which  is  the 
damaged  contents  of  word  1 of 
try_me . ) 

P2  was  not  able  to  read  try_me. 

(See  value  in  status_code, 
condition_found,  or  word_read.) 

P2  was  not  able  to  execute  try_me. 
(See  value  in  status_code, 
condition_found , or 
result_of_execution. ) 

P2  did  not  encounter  the  condition 
"no_write_permission"  when 
attempting  to  write  into  try_me. 

(See  value  in  status_code,  or 
condition_found . ) 

P2  did  meet  "no_write_permission" , 
but  nevertheless  damaged  word  1 
of  try_me . (See  value  in  word_read, 
which  is  the  damaged  contents  of 
word  1 of  try_me  . ) 

P2  was  not  able  to  read  try_me. 

(See  the  value  in  status_code, 
condi tion_found,  or  word_read.) 

P2  was  not  able  to  write  into  try-me. 
(See  value  in  status_code  or 
condition_found. ) 
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Error  on  other 


4200 


4300 


5000 


5100 


5200 


5300 


test  sex  acl 


terminal  Meaning 


P2  was  able  to  write  into  try_me, 
but  did  so  incorrectly.  (See 
value  in  word_read,  which 
should  have  been  all  7s  after 
write . ) 


P2  did  not  encounter  the  condition 
"no_execute_permission"  when 
attempting  to  execute  try_me. 

(See  value  in  status_code, 
condition_found , or 
result_of_execution. ) 

P2  was  not  able  to  read  try_me. 

(See  value  in  status_code, 
condition_found , or  word_read.) 

P2  was  not  able  to  execute  try_me . 
(See  value  in  status_code, 
condition_found , or 
result_of_execution . ) 

P2  was  not  able  to  write  into  try_me . 
(See  value  in  status_code,  or 
condition_found . ) 

P2  was  able  to  write  into  try_me, 
but  did  so  incorrectly.  (See 
value  in  word_read,  which  should 
have  been  all  7s  after  write.) 


218 


test  seg  acl 


test_seg_acl 


Error  on  other  terminal  Meaning 


6000  P2  did  not  encounter  the  condition 

"seg_fault_error"  when 
attempting  to  read  the  previously 
initiated  try_me  after  all  access 
rights  had  been  removed.  (See 
value  in  status_code, 
condi tion_found,  or  word_read.) 
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test_seg_auth 


Command 


Name:  tes^seg^auth,  tsa 

Phis  command  utilizes  a special  test  directory  to  check  that  the 
access  isolation  mechanism  works  properly  with  respect  to  segments. 

In  order  to  use  this  command  properly,  the  special  test  directory  must 
first  be  created  using  the  exec_com  "create_test_seg.ec" . 

Usage 


test  seg  auth  -dirname- 

1)  dirname  is  the  pathname  of  the  special  test  directory  described 
below.  If  missing,  the  working  directory  is  used. 


Notes 


The  authorization  of  the  process  calling  this  command  must  be  a 
certain  level  and  category  set  combination  as  specified  in  the  write- 
up to  create_test_seg.ec.  The  user  does  not  need  system  privilege  to 
run  this  command  — in  fact,  he  probably  shouldn't  have  it  if  the  con- 
trols are  to  be  tested  properly. 

If  the  test  succeeds,  no  error  messages  will  be  printed.  If  the 
test  fails,  a message  will  be  printed  indicating  the  reason  for  the 
failure  (bad  status  code  or  condition),  the  expected  status  code  or 
condition,  and  the  segment  that  was  being  referenced  when  the  error 
occurred.  The  access  class  of  the  segment  can  be  determined  from  the 
segment's  pathname  (see  the  write-up  of  create_test_seg.ec) . 
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tipc_set_up 


Subroutine 


Name : tipc_set_up 

The  tipc_set_up  subroutine  is  called  by  the  test_ipc  command  from 
the  first  terminal.  It  does  the  following: 

1)  creates  a temporary  segment  "multi_process_info"  in  the  home 
directory  of  the  user  at  the  first  terminal. 

2)  converts  the  six  arguments  supplied  to  the  test_ipc  command 
to  internal  form.  It  then  stores  them  in  the  segment 

mult i_process_info . 

3)  prints  messages  instructing  the  user  to  go  to  a second  ter- 
minal and  call  test_ipc  without  arguments. 

4)  accepts  input  from  the  user  about  his  session  on  that  second 
terminal . 

5)  does  a new_proc  to  a process  with  authorization  equal  to 
authl  as  in  the  writeup  of  the  test_ipc  command. 


Usage 

declare  tipc_set_up  entry  (char(#),  char(»),  char(*),  char(»), 
char(*),  char(*)); 


call 

tipc_set_up 

(strl,  str2,  str3, 

str4 , 

str5,  str6); 

1) 

str  1 

is  the  authorization  authl. 
test_ipc  command.  (Input) 

See  the  writeup  of  the 

2) 

str2 

is 

the 

authorization 

auth2 . 

( Input) 

3) 

str3 

is 

the 

authorization 

auth3 . 

(Input) 

4) 

str4 

is 

the 

authorization 

auth4 . 

( Input) 

5) 

str5 

is 

the 

authorization 

auth5. 

(Input) 

6) 

str6 

is 

the 

authorization 

auth6. 

( Input) 
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try_di preference 


Subroutine 


Name : try_di r_reference_ 

This  subroutine  references  a given  directory  using  all  the  hcs_ 
calls  documented  in  the  MPM  (including  SWG).  The  caller  supplies  the 
name  of  a directory,  and  the  effective  access  mode  he  expects  he  has 
on  that  directory.  This  subroutine  then  checks  to  make  sure  that  the 
expected  access  mode  is  enforced  by  all  hcs_  calls  that  depend  on  that 
mode . 


ieclare  try_dir_reference_  entry  (char(*),  chard),  chard), 
chard) , bit(1),  fixed  bin ( 35) ) ; 

call  try_dir_reference_  (parent,  dirname,  segname,  mode,  upgrade, 
error) ; 


1 ) parent 

2)  dirname 

3)  segname 

4)  mode 


5)  upgrade 


6)  error 


is  the  name  of  the  directory  to  which  access  is  to  be 
tested.  (Input) 

is  the  name  of  a subdirectory  within  parent.  (Input) 

is  the  name  of  a segment  within  parent.  (Input) 

is  the  expected  effective  access  mode  to  parent.  This 
value  may  be  one  of  the  strings:  "n" , "s" , or  "sm". 

( Input) 

is  "1"b  if  the  access  class  of  parent  is  not  less  than 
the  current  process  authorization.  In  this  case,  the 
parent  of  parent  must  be  at  an  equal  or  lower  access 
class  than  the  current  process  authorization.  If  par- 
ent is  at  an  equal  or  lower  access  class,  this  value 
must  be  "0"b,  (Input) 

is  zero  if  no  errors  or  inconsistencies  occurred  during 
the  test.  If  nonzero,  a positive  value  is  a standard 
storage  system  status  code  indicating  that  the  pathname 
of  parent  was  bad,  or  that  some  temporary  segments 
could  not  be  created.  If  -2,  the  test  was  completed, 
but  some  error  was  detected  in  the  system.  The  error 
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message(s)  is  printed  on  user_output.  (Output) 

Notes 

There  are  certain  restrictions  on  the  contents  of  parent  and  its 
attributes.  They  are  listed  below: 


quota 

parent 

>1 

dirname 

0 

segname 

ACL  for  user 

(see  below) 

sma 

rew 

bi tcount 

— 

0 

1 

rings 

7,7 

7,7 

4, M, 4 

safety  switch 

off 

off 

off 

max  length 

>1 

>1 

1024  words 

The  ACL  of  parent  depends  on  the  mode  and  properties  to  be  tested.  If 
only  ACLs  are  being  tested,  a3  opposed  to  access  isolation,  the  access 
mode  to  parent  should  be  the  mode  being  tested.  If  access  isolation 
is  being  tested,  the  ACL  of  parent  should  be  sma  for  the  user.  The 
effective  mode,  in  this  case  (which  depends  on  the  access  class  of 
parent  or  its  parent),  should  be  the  mode  being  tested.  Note  that  if 
upgrade  is  set,  the  effective  mode  should  be  "null",  since  there  is 
never  any  access  to  a directory  of  a higher  access  class. 

In  addition  to  the  above  attributes,  the  segment  should  contain 
all  zeros  except  the  first  bit,  which  should  be  "1"b.  The  directory  — — 
dirname  should  be  empty,  a^d  parent  should  contain  no  other  entries 


try_reference 


ti”y_reference_ 


Subroutine 


Name : try_reference_ 

This  subroutine  attempts  to  reference  a specified  segment  in  one 
of  several  modes  (read,  write,  execute,  or  call)  and  returns  any  con- 
dition name  or  error  code  resulting  from  the  reference. 

Entry : try_reference_$seg 

This  entry  requires  a pointer  to  the  segment  to  be  referenced. 


Usage 


declare  try_reference_$seg  entry  (ptr,  char(1),  bi t ( 36 ) aligned, 
char ( * ) , char(32),  fixed  bin(35)); 


call  try_reference_$seg  (segptr,  mode,  data,  condition_wanted , 
condition_name , code); 

1)  segptr  is  a pointer  to  the  segment  and  word  to  be  refer- 

enced. (Input) 

2)  mode  is  one  of  the  following: 


"r"  read  the  specified  word. 

"w"  write  the  specified  word. 

"e"  call  the  specified  word  using  a transfer 
instruction . 

"c"  call  the  specified  word  using  a call6  or 
callsp  instruction. 


( Input) 


3)  data  If  "r"  was  specified,  the  data  read  will  be  stored 

here.  (Output) 

If  "w"  was  specified,  this  is  the  data  to  be  writ- 
ten. (Input) 

If  "e"  or  "c"  was  specified,  this  argument  will  be 
passed  to  the  procedure  being  referenced.  The 
procedure  may  store  a value  into  this  argument  or 
it  may  obtain  a value.  (Input/Output) 
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4)  condi tion_wanted  If  not  zero  length,  this  should  be  a condition 

name,  such  as  "no_read_permission" , which  will  be 
interpreted  as  a condition  to  be  expected  by  the 
particular  reference.  If  the  condition  resulting 
is  the  expected  condition,  no  condition  name  will 
be  returned  in  "condi tion_name" . If  no  condition 
occurred,  and  "condition_wanted"  is  not  null,  the 
string  "access_allowed"  will  be  returned.  If  this 
argument  is  zero  length  or  blank,  any  condition 
that  occurs  will  be  returned . (Input) 


5)  condition  name 


If  the  condition  resulting  from  the  reference  does 
not  match  "condition_wanted" , the  condition  name 
is  returned  here.  If  "condition_wanted"  was  not 
null,  and  no  condition  occurred,  the  string  "ac- 
cess allowed"  will  be  returned  here,  (Output) 


6)  code 


This  is  normally  zero  for  most  hardware  condi- 
tions. However,  if  a call  to  find_condition_info_ 
supplies  a valid  error_table_  code,  that  code  will 
be  returned  here.  If  this  occurs,  the  condition 
mechanism  has  probably  malfunctioned. 


Entry : try_reference_$f ile 

This  entry  operates  similar  to  try_reference_$seg,  except  that 
the  name  of  the  segment  is  supplied  instead  of  a pointer.  The  main 
difference  is  that  the  status  code  may  reflect  a failure  to  initiate 
the  segment  due  to  null  access  or  bad  pathname.  If  initiate  fails, 
the  status  code  should  always  be  non  zero  and  condition_name  will  al- 
ways be  null. 


declare  try_reference_$file  entry  (char(*),  char(»),  ptr,  fixed 
bin,  char(1),  bit(36)  aligned,  char(*),  char(32),  fixed 
bin( 35) ) ; 


call  try_reference_$file  (dirname,  ename,  ptr,  offset,  mode, 
data,  condition_wanted , condition_name , code); 
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1)  dirname  is  the  directory  name  portion  of  the  pathname  of  the  seg- 

ment. If  zero  length,  the  working  directory  will  be  used. 
( Input) 

2)  er  une  is  the  name  of  the  segment.  (Input) 

3)  se  ptr  is  a pointer  to  the  word  referenced.  It  is  null  if  initi- 

ate failed.  (Output) 

4)  offset  is  the  location  within  the  segment  to  be  referenced.  (In- 

put) 

5)  mole  is  as  above.  (Input) 

6)  data  is  as  above.  (Input/Output) 

7)  condition_wanted 

is  as  above.  (Input) 

3)  co- dition_name 

is  blank  if  code  is  nonzero.  Otherwise,  it  is  set  as 
above.  (Output) 

9)  code  If  not  zero,  initiation  failed  for  some  reason  or  the  con- 
dition mechanism  failed  as  described  above.  If  zero,  ini- 
tiation was  successful.  (Output) 


Entry : try_reference_$entry 

This  entry  accepts  a pathname  of  the  segment  and  an  entry  name  of 
the  form  pathname$entryname . The  search  rules  are  used  to  locate  the 
segment  if  the  pathname  is  just  a segment  name  in  a manner  similar  to 
the  search  for  a command.  If  "$entryname"  is  not  specified,  it  is  as- 
sumed to  be  the  same  as  the  segment  name.  This  entry  may  return  a 
status  code  if  the  segment  could  not  be  found  or  initiated. 

Usage 


declare  try_reference_$entry  entry  (char(*),  char(1),  bit(36) 


aligned,  char(*),  char(32),  fixed  bin(35)); 


k ft 
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try_referenc:e 


try_reference. 


call  try_reference_$entry  (pathname,  mode,  data, 
condition_wanted , condition_name , code); 

1)  pathname  is  the  relative  pathname  of  the  segment  as  described 

above.  The  specific  entry  point  specified  will  be  the 
word  referenced.  (Input) 

2)  - 6)  are  as  above. 
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03  condl t 1 on_t ound  charC32>* 

03  aord.rtad  blt(3€)« 
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465  If  Cstatus_cod*  -=  0) 

466  than  do; 

467  call  process_l_c leanur 
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